[PATCH] D95370: [ELF] Infer OSABI from input files for -m options without explicit OSABI

Sat Jan 30 18:50:50 PST 2021

MaskRay added a subscriber: peter.smith.
MaskRay added a comment.

GNU as and GNU ld by default emit ELFOSABI_NONE, but will promote ELFOSABI_NONE to ELFOSABI_GNU if certain GNU ABI ELF features are used.
The single value nature makes it difficult to encode more than one ABI flavors. In practice many OSABI platforms adopt some GNU extensions.
It is possible to use extensions from more than one osabi platforms and we treat ELFOSABI_GNU an overridable osabi value (can be overridden by ELFOSABI_FREEBSD).

In https://sourceware.org/bugzilla/show_bug.cgi?id=12913#c9

> It may have been an unfortunate choice to use EI_OSABI for the meaning that ELFOSABI_GNU has.  But it's already been done and it's too late now.

I think that is a good summary from a retrospective viewpoint. It would be nice if GNU extensions could be taken as need, used as mixins. A single osabi value does not encode this intention well.

inferMachineType infers ekind/e_machine/EI_OSABI. ekind/e_machine are good to infer but EI_OSABI is not.
This patch makes the logic smarter: skipping ELFOSABI_NONE, but I don't see it fundamentally improves things.

E.g. if the first few object files have osabi values of ELFOSABI_NONE, ELFOSABI_GNU, ELFOSABI_FREEBSD, ELFOSABI_FREEBSD, ...
Do we pick ELFOSABI_GNU as the output? It is not better than ELFOSABI_NONE as ELFOSABI_FREEBSD should be the correct one.

The problem, according to @kevans, is no fbsd specific `-m` is specified `clang/lib/Driver/ToolChains/FreeBSD.cpp`, and ultimately the problem is that GNU ld does not understand a FreeBSD flavor RISC-V emulation...
So seems that binutils should be fixed. If you can detect `-fuse-ld=`, you can pass the emulation...

(@peter.smith)

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D95370/new/

https://reviews.llvm.org/D95370