From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97241 invoked by alias); 13 Oct 2016 12:09:22 -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 97207 invoked by uid 89); 13 Oct 2016 12:09:20 -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=e_flags, exhaust, Properties, denote 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: userp1040.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> Date: Fri, 01 Jan 2016 00:00:00 -0000 In-Reply-To: <62be87c7-53c1-b4f4-4ad3-57683464ffdd@gmail.com> (Suprateeka R. Hegde's message of "Thu, 13 Oct 2016 12:04:45 +0530") Message-ID: <87lgxspjho.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/msg00002.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.