From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23705 invoked by alias); 13 Oct 2016 16:37:12 -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 23686 invoked by uid 89); 13 Oct 2016 16:37:11 -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=marchesi, jose, Jose, HTo:D*oracle.com 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-pf0-f179.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=TKI17w6YRb44FnFo8mcCp444apdEWhUAbSwwzIClKD8=; b=ksXqgm4TrFc1xeOvPfNHwNYjWIqFDRo1hhsfEjQqiqHAGnp3LlCAk1B36sDk9Gn5qw CeL/1egCY92UMCdwwtwp14FyhQbzPJEpa/kvbhqUGKin70UYLuNwbphimOu8jwZktlX+ +Y4SALm9gOs1FIR0Oqo89Eie8xBqEHgJT5G9TwRH/e0afoVAB7pK2ECHO5BfrYxHPltD 3NRMu1ixfbDPWGwBFk3/Vx3fK0Ibq5dz+/8zpbKOXYxrwqMX+TqZLev4iNeqmXfzWNS9 KJh3VJpkKDPu7AmXc30cGgvnohamVxxHLDIG89e7ijiNWewbryAUt06uSDCER50hThxS TfrQ== 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=TKI17w6YRb44FnFo8mcCp444apdEWhUAbSwwzIClKD8=; b=bYDjBgMdcivEA1HcLht9+FLxO0DnbdKTW+D9xwHrHsxrGdNvngBMpDaRbjvMIAo23v 0OqF3osojKhwd3TTBViLl3jOtyb25lUop3fJyvtkOP1eDEF+mA2iVyaYa+72dQko1s2g 7eidKQsCJkYOtxlzIRJ6PMyeqOo3FBTll+JFrnXvBI6MpROFeDfhvAvvbHfZC/FVAlAj KtJFM+SYhgtxe7rdHGCT5ZXQqTGyqqGNuKQr30v+1dSnhViez9MfP8YNDWnsUOY1IkjI GdPZs4AYQzbT0OCugl4e6XeZPdDL12+JKSXIn029AvA9Mfur29GDguvlhs5nPOgbHGAN dWCQ== X-Gm-Message-State: AA6/9RnEz2jxabd9bRIT1/RE1GlkmGwKv5suxAzeoMdiJ6UKEpl1i9XDaMUCi4LYnPBQGA== X-Received: by 10.98.67.133 with SMTP id l5mr11244755pfi.170.1476376628072; Thu, 13 Oct 2016 09:37:08 -0700 (PDT) Reply-To: hegdesmailbox@gmail.com Subject: Re: RFC: Program Properties References: <62be87c7-53c1-b4f4-4ad3-57683464ffdd@gmail.com> <87lgxspjho.fsf@oracle.com> To: "Jose E. Marchesi" Cc: "H.J. Lu" , gnu-gabi@sourceware.org From: Suprateeka R Hegde Organization: HEGDESASPECT Message-ID: 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: <87lgxspjho.fsf@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 161013-0, 13-10-2016), Outbound message X-Antivirus-Status: Clean X-SW-Source: 2016-q4/txt/msg00003.txt.bz2 On 13-Oct-2016 05:07 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 addition, we can have arch-version mask just like Intel Itanium, MIPS, etc. Of course thats slightly expensive but gives more space. And if we can add asserts in compilers/binutils to check the range of e_flags to be within the mask, then we can make it efficient too. Am I missing anything?/ -- Supra