From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10765 invoked by alias); 13 Oct 2016 18:01:26 -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 10658 invoked by uid 89); 13 Oct 2016 18:01:25 -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=-2.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS,UNPARSEABLE_RELAY autolearn=ham version=3.3.2 spammy=ordered, oracle, Oracle, our X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS,UNPARSEABLE_RELAY autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: aserp1040.oracle.com From: jose.marchesi@oracle.com (Jose E. Marchesi) To: Suprateeka R Hegde Cc: "H.J. Lu" , gnu-gabi@sourceware.org Subject: Re: RFC: Program Properties References: <62be87c7-53c1-b4f4-4ad3-57683464ffdd@gmail.com> <87lgxspjho.fsf@oracle.com> Date: Fri, 01 Jan 2016 00:00:00 -0000 In-Reply-To: (Suprateeka R. Hegde's message of "Thu, 13 Oct 2016 22:07:06 +0530") Message-ID: <87lgxsnmtl.fsf@oracle.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Source-IP: userv0021.oracle.com [156.151.31.71] X-SW-Source: 2016-q4/txt/msg00004.txt.bz2 > > 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. Also, the only practical way to define a "minimum ISA" is through these hardware capabilities: the sparc specs and implementations are not linear. As a result the ordered opcodes architectures we define in opcodes (that correspond to ISAs in our case) are rather artificial. Consider for example the `v9v' opcodes architecture: v9v: V9 with OSA2011 and T4 additions, integer multiply and Fujitsu fp multiply-add. Where OSA2011 (Oracle SPARC Architecture 2011) is an extension to SPARC-V9 (a spec) and "T4 additions" refer to the T4 extensions to OSA2011, plus a bunch of specific instructions (integer multiply and the FJ floating-point multiply-add). So yes, at least in sparc we need to live with many many hardware capabilities, and these capabilities are only increasing with the introduction of new versions of the spec and processors.