From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84357 invoked by alias); 10 Jun 2016 21:23:04 -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 84322 invoked by uid 89); 10 Jun 2016 21:23:03 -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=0.5 required=5.0 tests=BAYES_05,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=H*F:U*roland, HX-Envelope-From:sk:roland@ X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_05,KAM_LAZY_DOMAIN_SECURITY 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: topped-with-meat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: hegdesmailbox@gmail.com Cc: gnu-gabi@sourceware.org Subject: Re: OSABI on Linux Distros In-Reply-To: Suprateeka R Hegde's message of Sunday, 5 June 2016 12:57:44 +0530 <7160c0e3-b49c-1ab8-c0d3-cee12355f895@gmail.com> References: <7160c0e3-b49c-1ab8-c0d3-cee12355f895@gmail.com> X-Shopping-List: (1) Inefficient party demolition (2) Ambivalent rhythmic directions (3) Inharmonious furniture Message-Id: <20160610212256.D5A772C39F7@topped-with-meat.com> Date: Fri, 01 Jan 2016 00:00:00 -0000 X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=Tvt12lnh c=1 sm=1 tr=0 a=WkljmVdYkabdwxfqvArNOQ==:117 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=xOMDEkDnFuufNNF2exYA:9 a=CjuIK1q_8ugA:10 X-SW-Source: 2016-q2/txt/msg00012.txt.bz2 > 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.