Re: toolchain/51238: ELF binaries don't carry ELFOSABI_NETBSD in their header

[Joerg Sonnenberger <joerg%bec.de@localhost>]

The following reply was made to PR toolchain/51238; it has been noted by GNATS.

From: Joerg Sonnenberger <joerg%bec.de@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: toolchain/51238: ELF binaries don't carry ELFOSABI_NETBSD in
 their header
Date: Fri, 17 Jun 2016 18:23:18 +0200

 On Fri, Jun 17, 2016 at 03:50:00PM +0000, David Holland wrote:
 > The following reply was made to PR toolchain/51238; it has been noted by GNATS.
 > 
 > From: David Holland <dholland-bugs%netbsd.org@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc: 
 > Subject: Re: toolchain/51238: ELF binaries don't carry ELFOSABI_NETBSD in
 >  their header
 > Date: Fri, 17 Jun 2016 15:47:21 +0000
 > 
 >  On Tue, Jun 14, 2016 at 08:20:01AM +0000, Joerg Sonnenberger wrote:
 >   >  >  Last I checked we don't have the same syscall table as SVR4, except
 >   >  >  when compat_svr4 is in use, so we hardly have the same OS ABI.
 >   >  
 >   >  It is not about system calls. It is about the implemented ABI. That's
 >   >  what we follow, including stack alignment on i386 etc. Looking at
 >   >  FreeBSD, they had more than enough problems with requiring tagging with
 >   >  the OSABI. It is a crude and limited hack. Heck, if you don't want to
 >   >  parse PT_NOTE yourself, call file(1).
 >  
 >  So the "OS ABI" is not the OS ABI, but something akin to the ELF
 >  version?
 
 Not exactly the ELF version, but it is essentially a marker for "I am
 using OS specific extensions to the normal platform rules". E.g. we
 should be marking the binaries if we introduce custom relocations. I
 don't think the TLS relocations for example qualify as they have all
 been submitted for allocation in the appropiate platform ABI
 supplementals.
 
 Joerg