From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111682 invoked by alias); 14 Oct 2016 13:35:58 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 111646 invoked by uid 89); 14 Oct 2016 13:35:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=ah, marchesi, jose, Jose X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mail-oi0-f54.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:subject:references:to:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=dKYfnNkVc2//MQj8lGXyk3YoIDvZnVTSFRMc04MZDDQ=; b=RdcvNSpKt69AvyLTjLwcwWG0T4qnab687yj1iYUijL6cQcuHxah62bZqOW7MYsPHEy b9AoqACubZ75Qdm5XAA7ByaEIaLW0xXQhxSMTJy+UPxIjkvFzOh2lAZEWgokk8DSJVqk LiQWsaZPTi/wvxBWFRyKfeEUxU80ry3yMDDaF9m0lhw960S8kTxz0pyQGalmIjmNebSH MVxYO3LRVBGIj43L79vBRH/93RCZLxuO/gI8UJFNVbUq0mtpFwljUoBUBlg1LQsxgsdT szDoQjBxTfmlBLgVMkvA6W+biDRgzW9XSIE5I77JxUjCFiEznIx9avMVMCb1i/Oop1yv KMZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=dKYfnNkVc2//MQj8lGXyk3YoIDvZnVTSFRMc04MZDDQ=; b=Vfza3FXnwLURhqZGieCBFT0dMBPdUfZXfgHy+X4jQbU0UNc+dObOtamPXg4O/cLUh/ ilhBHJCrrsH5SLyIlbzYm4L2x8vuGTccoMksThQFoNDPUMu0dqrnyvOswlWt7B07dGIp o2IQbHu/78Eft/bjye4YMaHU2k+OrfPYzM6cEDJx3tjwOQQlcHlwe8tT/an/PltMZ9d/ 1B/3mBvLsttrBv2sajPoOHNLJwI+guCwGyV18wPvMJ6OUH1ysEc9V81GNxPJSENczcT0 kpd1RWsfQLTOj1OsMXPaF2pHI/2hCHHLm0mF1wOPjXPRq10M4a1tJ9c4NRJOTchF3aK5 7Kyw== X-Gm-Message-State: AA6/9RmRZA/06Jw7bNyP3MZhBJjF8aQ3mpYqJU1ASbzXam1quqyAg0qhxxCXFSwruzd5FA== X-Received: by 10.157.34.106 with SMTP id o97mr6573184ota.134.1476452153750; Fri, 14 Oct 2016 06:35:53 -0700 (PDT) Reply-To: hegdesmailbox@gmail.com Subject: Re: RFC: Program Properties References: <62be87c7-53c1-b4f4-4ad3-57683464ffdd@gmail.com> <87lgxspjho.fsf@oracle.com> <87lgxsnmtl.fsf@oracle.com> To: "Jose E. Marchesi" Cc: "H.J. Lu" , gnu-gabi@sourceware.org From: Suprateeka R Hegde Organization: HEGDESASPECT Message-ID: <836079bc-1309-146c-889e-7ceec926d1ad@gmail.com> Date: Fri, 01 Jan 2016 00:00:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <87lgxsnmtl.fsf@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 161013-1, 13-10-2016), Outbound message X-Antivirus-Status: Clean X-SW-Source: 2016-q4/txt/msg00006.txt.bz2 On 13-Oct-2016 11:38 PM, Jose E. Marchesi wrote: > > > > > 1. Minimum ISAs. Executables and shared objects, which are optimized > > > specifically to run on a particular processor, will not run on processors > > > which don't support the same set of ISAs. Since x86 only has EM_IAMCU, > > > EM_386 and EM_X86_64 ELF machine codes, run-time loader needs additional > > > information to tell if an executable or a shared object is compatible > > > with available ISAs. > > > > Why cant the following be defined as processor specific e_flags (like > > other processors do) in elf.h itself? > > > > It is easy to exhaust the space of EF_* flags. In sparc this happened > > many years ago, so we had to start using the tags Tag_GNU_SPARC_HWCAPS > > and Tag_GNU_SPARC_HWCAPS2 to denote hardware capabilities. > > Hmm. Looks reasonable. But I still have some points to ponder: > > e_flags is processor specific and I thought each processor has its own > space. And e_flags is also 4 byte size (purpose is unsigned integer). > > The proposed numbering scheme is already at 17 and 14 more left-shifts > left. It would be same as e_flags capacity. > > In SPARC we have more than 32 hardware capabilities, that can be > combined in any way, so 4 bytes are not enough. Ah! Thats the key here. Combination is possible. So you need unique bit positions. And the case is true here too. The following is valid as per the proposal: GNU_PROPERTY_X86_ISA_1_USED = GNU_PROPERTY_X86_ISA_1_486 | GNU_PROPERTY_X86_ISA_1_686 Then we may soon need more bits. On 14-Oct-2016 07:54 AM, Carlos O'Donell wrote: > To kick off that discussion I have questions that range from the compiler > to the dynamic loader: We may want to propagate this to package managers to enforce minimum ISA. If the machine does not support minimum ISA, then do not install or issue warning. And then propagate this to archive libraries too. For instance, allow an archive library to contain two foo.o files one built with minimum ISA-1 and another built with minimum ISA-2. And depending on the main program's minimum ISA, let the linker pick the right one. And there are two parts in case of hardware capabilities. One that is recorded in the ELF. And the other, the actual one (machine) where this ELF runs. Is the loader going to check actual hardware using cpuid? Or do we want to propagate this proposal to the kernel also and keep the actual hardware capabilities in the ELF image of the kernel (may not work with a UEFI based kernel) ? Its better we discuss as many use cases as possible (as you said) and make relevant changes in the design right now. > (6) Is there any historical implementations of anything like this? On HP-UX (both on PA-RISC and Intel Itanium) we have similar things. We also have a tool called "chatr" (stands for CHange program ATtRibutes) that can be used to change program attributes post build. -- Supra