Re: Wrong OSABI for GCC from Ports

From: Konstantin Belousov <kostikbel_at_gmail.com>
Date: Tue, 24 Sep 2024 19:48:36 UTC
On Tue, Sep 24, 2024 at 09:05:45AM -0700, Alex Arslan wrote:
> 
> > On Sep 24, 2024, at 4:08 AM, Lorenzo Salvadore <developer@lorenzosalvadore.it> wrote:
> > 
> > On Tuesday, September 10th, 2024 at 18:13, Alex Arslan <ararslan@comcast.net> wrote:
> > 
> >> 
> >> 
> >> I noticed that GCC and its associated libraries, when installed from pkg
> >> on FreeBSD 14.1 AArch64, have an OS/ABI value of NONE (0) rather than
> >> FreeBSD (9), as reported by readelf --file-header. I also observed this
> >> when cross compiling GCC for FreeBSD 13.2 AArch64 on Alpine Linux; I
> >> assumed it was an issue with the cross compilation setup until I realized
> >> that the one from pkg exhibited the same thing. This does not seem to
> >> occur with x86_64, neither from pkg nor cross compiled. Does anyone know
> >> why this would happen and whether it could be addressed with a patch to
> >> GCC? Apologies if this is already known and has been discussed somewhere.
> > 
> > Hello,
> > 
> > I am the maintainer for the GCC ports, sorry for the late response.
> > I have created a bug report to track this issue, so we do not forget
> > about it:
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281681
> 
> Thank you! Mikäel Urankar pointed out that what I described sounds similar
> to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252490 and I believe
> it is actually the exact same phenomenon as what I described.
> 
> > Is the bug only about the value reported by readelf? Or is the compiler
> > actually broken? If the compiler works, what is the value reported by
> > readelf for binary compiled by it?
> 
> The compiler itself works just fine, it's only the OS/ABI in the ELF file
> header that isn't set to FreeBSD. It does have a FreeBSD branded ELF note
> though. Binaries produced by cc set OS/ABI to FreeBSD and include the ELF
> note, whereas binaries produced by the GCC port (13.2.0) have OS/ABI set
> to NONE but do still include the branded ELF note. The produced binaries
> are similarly functional.
> 
> Based on the discussion in Mikäel's bug report, it sounds like this
> behavior is expected, so I guess there's no bug after all?

Kernel needs ELF note to decide to use FreeBSD emulation for the binary.
So lack of the OSABI branding might only affect utilities like readelf
that AFAIR indeed change their behavior on decoding e.g. dwarf unwind
information, but I am not sure.

On the other hand, since gcc uses base system' csu, it includes the
noinit note, but gcc is not configured with --enable-initfini-array.
This makes all static global constructors non-functional.