[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: toolchain/51238: ELF binaries don't carry ELFOSABI_NETBSD in their header
The following reply was made to PR toolchain/51238; it has been noted by GNATS.
From: Joerg Sonnenberger <joerg%bec.de@localhost>
Subject: Re: toolchain/51238: ELF binaries don't carry ELFOSABI_NETBSD in
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
> 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
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
Main Index |
Thread Index |