lld: Set OS/ABI version to ELFOSABI_GNU if object contains GNU symbols

[marxin]

This is a spin of #40541, this time for LLVM linker:

ifunc.c:

static int implementation (void)
{
  __builtin_printf ("'ere I am JH\n");
  return 0;
}

static __typeof__ (implementation)* resolver (void)
{
  return implementation;
}

extern int magic (void) __attribute__ ((ifunc ("resolver")));

int main ()
{
  return magic () != 0;
}

$ clang ifunc.c -fuse-ld=lld && readelf -a a.out
$ readelf -a a.out | less
...
  OS/ABI:                            UNIX - System V
...
    34: 00000000000017b0     8 <OS specific>: 10 GLOBAL DEFAULT   15 magic

While bfd and gold does:

$ gcc-12 ifunc.c && readelf -a a.out | less
...
  OS/ABI:                            UNIX - GNU
...
    25: 000000000040115b    11 IFUNC   GLOBAL DEFAULT   15 magic

@MaskRay

[marxin]

@rearnsha

[llvmbot]

@llvm/issue-subscribers-lld-elf

[MaskRay]

I mentioned this on https://maskray.me/blog/2021-01-18-gnu-indirect-function

Changing ELFOSABI_NONE to ELFOSABI_GNU is entirely cosmetic for the ifunc case. The only difference is that readelf -s does not show IFUNC unless the osabi is ELFOSABI_GNU or ELFOSABI_FREEBSD. rtld implementations don't care about the osabi for ifunc, either. GNU ld handles type 10 as ifunc even in ELFOSABI_NONE, so does other linkers supporting ifunc.

I don't think changing ELFOSABI_NONE to ELFOSABI_GNU for STT_GNU_IFUNC is a necessary linker change, but changing ELFOSABI_NONE to ELFOSABI_GNU when there is an input relocatable file using ELFOSABI_GNU may make sense, but again it is like adding code for something which doesn't really matter.

[EnergonV]

Using U++, msys2(clang64), the options are:
BUILDER = "CLANG";
COMPILER = "clang++.exe";
COMMON_OPTIONS = "--target=elf_x86_64 --sysroot=d:\clang-15.0.6-x86_64-linux";
COMMON_CPP_OPTIONS = "-Id:\clang-15.0.6-x86_64-linux\include -Id:\clang-15.0.6-x86_64-linux\include\gtk-3.0 -Id:\clang-15.0.6-x86_64-linux\include\glib-2.0 -Id:\clang-15.0.6-x86_64-linux\include\pango-1.0 -Id:\clang-15.0.6-x86_64-linux\include\harfbuzz -Id:\clang-15.0.6-x86_64-linux\include\cairo -Id:\clang-15.0.6-x86_64-linux\include\gdk-pixbuf-2.0 -Id:\clang-15.0.6-x86_64-linux\include\atk-1.0 -Id:\clang-15.0.6-x86_64-linux\include\freetype2";
COMMON_C_OPTIONS = "";
COMMON_LINK = "-fuse-ld=lld -Wl,--gc-sections";
COMMON_FLAGS = "";
DEBUG_INFO = "";
DEBUG_BLITZ = "0";
DEBUG_LINKMODE = "0";
DEBUG_OPTIONS = "-O0";
DEBUG_FLAGS = "";
DEBUG_LINK = "";
RELEASE_BLITZ = "0";
RELEASE_LINKMODE = "0";
RELEASE_OPTIONS = "-O3 -ffunction-sections -fdata-sections";
RELEASE_FLAGS = "";
RELEASE_LINK = "-fuse-ld=lld -Wl,--gc-sections";
DEBUGGER = "gdb";
ALLOW_PRECOMPILED_HEADERS = "0";
DISABLE_BLITZ = "1";
PATH = "e:\dinrus\clang32\bin";
INCLUDE = "d:\clang-15.0.6-x86_64-linux\include";
LIB = "d:\clang-15.0.6-x86_64-linux\lib";
LINKMODE_LOCK = "0";

the result is:
ld.lld: error: D:/upp/out/src/DinrusIDE/Linux64.Gui.Main\BaseDlg.o: unknown file type
ld.lld: error: D:/upp/out/src/DinrusIDE/Linux64.Gui.Main\SelectPkg.o: unknown file type
ld.lld: error: D:/upp/out/src/DinrusIDE/Linux64.Gui.Main\UppWspc.o: unknown file type
ld.lld: error: D:/upp/out/src/DinrusIDE/Linux64.Gui.Main\NewPackageFile.o: unknown file type

The question is: how to tell it to work with elf64?!

[uweigand]

I don't think changing ELFOSABI_NONE to ELFOSABI_GNU for STT_GNU_IFUNC is a necessary linker change, but changing ELFOSABI_NONE to ELFOSABI_GNU when there is an input relocatable file using ELFOSABI_GNU may make sense, but again it is like adding code for something which doesn't really matter.

I agree it doesn't really matter de facto today - it's still a bit odd to have different linkers behave differently here.

As to whether the linker should check the features directly or rely on input objects, I think the idea was that it is possible for the final executable to no longer require a GNU feature even though an input object did use it. (E.g. only reference to an ifunc symbol was from a section that got discarded; or maybe the symbol was resolved locally.)