From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23160 invoked by alias); 13 Jun 2016 15:26:10 -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 23030 invoked by uid 89); 13 Jun 2016 15:26:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.1 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=segment, constitute X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW 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: mail-qt0-f170.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=EX8l01kSblxEnBl4p/YUekSAOWvMgvr5mhsY7D78lDA=; b=VmOnRT0PTrZ2PjfRzqXZzI3fwVyOa+BSRDPG7O5CcCxseksV8bkaQ/XQx36avVwOfL 5VSXg68Z6DxM4LcpXk08aU6sdFzD6gl/QwgD+g2opcKsMey01O1nR0xbglhcSIAwV6w/ dIbWv6gceSICC95l6o12XGde0CkUTEZRk/tD0AZ99kMsMPqIvx7ODRDz5hYjMJK7R5zN Vx3UWSD9UyHGHOWaAoLfAS3zLpekNC+YC038NiLL+Cesf0LjanO5qNBOKVcp70+4nqtn W6s+qNnj4o2JrBqn3b7Q1vhRpSg561G0eiLNX/7wkHyRZueZTyoZn4QOTHCoCtNfPuSz lIFg== X-Gm-Message-State: ALyK8tJVrqZcRYsrMXBBNfhOILiC8N8W8XcdRNahL0DW76VUvhx/3FqDWbZcMqq7W1wVzPeP X-Received: by 10.200.47.212 with SMTP id m20mr14943834qta.53.1465831563200; Mon, 13 Jun 2016 08:26:03 -0700 (PDT) Subject: Re: OSABI on Linux Distros To: hegdesmailbox@gmail.com, Roland McGrath , "H.J. Lu" References: <7160c0e3-b49c-1ab8-c0d3-cee12355f895@gmail.com> <20160610212256.D5A772C39F7@topped-with-meat.com> Cc: gnu-gabi@sourceware.org From: Carlos O'Donell Organization: Red Hat Message-ID: Date: Fri, 01 Jan 2016 00:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-q2/txt/msg00016.txt.bz2 On 06/11/2016 02:44 AM, Suprateeka R Hegde wrote: > On 11-Jun-2016 02:52 AM, Roland McGrath wrote: >>> What is the reason why we emit OSABI value as "UNIX - System V" >>> (ELFOSABI_SYSV) even on GNU/Linux systems? Shouldn't it be just "GNU" >>> (ELFOSABI_GNU)? >> >> In GNU systems the use of this field is specifically to indicate that >> certain GNU extensions to ELF are used in the particular object. In >> particular, if any .dynsym entries use STT_GNU_IFUNC o STB_GNU_UNIQUE, >> then e_ident[EI_OSABI] must be ELFOSABI_GNU. > > OK. I understood this part. But then I did not know this set is > partial. I thought use of *any* GNU specific extension should mark it > as GNU OSABI. > > For instance, GNU_RELRO, GNU_EH_FRAME, GNU_STACK, etc. Even with all > these, it is still marked SYSV ABI. I'm not as authoritative on this as Roland is, but in my opinion I expect that because all three of these entries are optional they do not constitute a change in the EI_OSABI. You can ignore GNU_RELRO without any problem, you just won't have a read-only segment after relocation. You can ignore GNU_STACK without any problems, it's information for the dynamic loader to set default stack permissions. When unset the glibc dynamic loader will use sensible per-machine defaults, likewise other implementations should also. The GNU_EH_FRAME can be ignored if you're not using the GNU-based unwinder which uses this PT_* entry to find .eh_frame_hdr. Other dynamic linkers should ignore program header segments they don't understand, and thus the above optionally processed entries should not change the EI_OSABI. > 1. Do we have a documented list of GNU extensions that are necessary > to mark an ELF as GNU ABI? Not that I am aware of. H.J. might better answer this question. > 2. Why the list is partial? Why not all GNU extensions? Only the required GNU extensions should mark EI_OSABI as ELFOSABI_GNU. If you don't implement STT_GNU_IFUNC or STB_GNU_UNIQUE then things actually fail. -- Cheers, Carlos.