From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99181 invoked by alias); 18 Jun 2016 08:04:33 -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 99171 invoked by uid 89); 18 Jun 2016 08:04:32 -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.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy= X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS 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-oi0-f50.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=YMf/OzzrWSsU7iHG8kBz1F3simm6m1EKLkWjdZJg8LQ=; b=hiY6jRo4GmEaoszhXofZM9nHBGR0TyalHpuBxcZGgyQAOMeElYwE/RGbV2mH2Fy+3f aup0N+vUlDNw6v+vLnK/rSytaCbl62RDpvqF2rkJXR0qyshUA288pATb3kxoKsPDs8pq i2sULXzeXqfneTh0U8kr9Apt07pHiieiR4kOQOkAFAfOM8XrHA9H6Fim1lAdRg48mPDN /Sh8YuKyRYhN8pvp8bAogzeujzf6u/O+pXUlHEdQqXdck9UvU7IlHK9MQNqlzjsNY464 OWtjkezFsHVul++qEhsVcJK1ruY6LYE+DbvehMAj97kkaOwOgSn27MM4ZCHrCMxKlX8I mQLQ== 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=YMf/OzzrWSsU7iHG8kBz1F3simm6m1EKLkWjdZJg8LQ=; b=EowLM9zlljaRxo+AEIEZpNU8o9anavuObNNay9bazXdGcj1aUjVNIcUNf67V5gQSgC qI6UyDXbmsEvwy8fgg0XhxCAKUghs692tXsAXO/y03zRubXO5qeqgmnJnAnCz8I5Shcl 1NxmWeag3eCRMBvusrIcd7O8voUzoVcQ6GJhKGKDRG2zj4tytusd2JrW4a5BSuFp4glZ ywnKPem95/TEQA6RV1DH062CWTcxMIg11mPdwwYOcCTkkNx3X9xq3S7ANQjqbNF554gg vpaJQ8zlCgY3O4FelC/71TiWjDvc3lHsHInq2sjKTO5aLMryRm2Kwe0nAfbG0TrMLxvz uG4A== X-Gm-Message-State: ALyK8tJMPzT7Xxof5dsTK6Se8fjM/oKvaFrhI9ENQRTeNkEbpvoWLq38estu/n+jnw3tXQ== X-Received: by 10.157.38.185 with SMTP id l54mr3994535otb.112.1466237068750; Sat, 18 Jun 2016 01:04:28 -0700 (PDT) Reply-To: hegdesmailbox@gmail.com Subject: Re: OSABI on Linux Distros References: <7160c0e3-b49c-1ab8-c0d3-cee12355f895@gmail.com> <20160610212256.D5A772C39F7@topped-with-meat.com> To: Carlos O'Donell , Roland McGrath Cc: 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.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 160617-3, 18-06-2016), Outbound message X-Antivirus-Status: Clean X-SW-Source: 2016-q2/txt/msg00028.txt.bz2 On 18-Jun-2016 10:41 AM, Carlos O'Donell wrote: > On 06/10/2016 05:22 PM, 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. Otherwise, it can be >> ELFOSABI_NONE (aka ELFOSABI_SYSV). In fact, it should be, and the >> tools (linkers) implement that distinction. This makes it possible >> for current tools (without special switches or whatnot) to produce >> binaries that are compatible with older dynamic linker implementations >> that did not support these GNU extensions to ELF. >> >> This is arguably a bad overloading of the original instead of >> EI_OSABI, but it's what's been done for GNU systems and so now it's an >> unchangeable part of the GNU ELF gABI. > > Sure we might have to document this in the GNU ELF gABI, but nothing > stops us from changing it and moving forward? > > Change binutils to generate ELFOSABI_GNU by default, with a > "special switch" to allow people to generate pre-2009 glibc ld.so > compatible binaries if they need it. You would need a sysroot to build > with so they'd be using probably similar vintage tools anyway and don't > have to worry. Then all binaries going forward are marked as being > ELFOSABI_GNU binaries. > > The use case of being able to use ELFOSABI_GNU to determine how to decode > values between PT_LOOS/PT_HIOS is the most relevant I've seen. > > Today with ELFOSABI_NONE you don't know how to decode those values, only > though if one assumes that PT_LOOS/PT_HIOS values can overlap between > any OS. Thats absolutely what I think. I have a patch. I shall post it here soon. And if we have good consensus, I shall talk to H.J to get this added to GNU-gABI. -- Supra