readelf doesn't pretty print symbol type of STT_GNU_IFUNC unless ELF header's EI_OSABI is set to ELFOSABI_GNU. Instead of "IFUNC", it prints out "<OS specific>:10".
Technically, GNU IFUNC is indeed a GNU extension, but all systems I know of do not require EI_OSABI to be set to ELFOSABI_GNU, so it is effectively a globally-reserved number. Given the situation, LLVM lld and mold do not bother to set EI_OSABI.
Could you make a change to readelf so that it always pretty-prints symbol type 10 for all ELF OSABIs?
Looking into readelf, I see the ident[EI_OSABI] == 0, thus it can be fixed with:
diff --git a/libebl/eblsymboltypename.c b/libebl/eblsymboltypename.c
index 0ff1722a..a5db53b0 100644
@@ -65,8 +65,7 @@ ebl_symbol_type_name (Ebl *ebl, int symbol, char *buf, size_t len)
snprintf (buf, len, "LOPROC+%d", symbol - STT_LOPROC);
else if (symbol == STT_GNU_IFUNC
&& ebl != NULL
- && (ident = elf_getident (ebl->elf, NULL)) != NULL
- && ident[EI_OSABI] == ELFOSABI_LINUX)
+ && (ident = elf_getident (ebl->elf, NULL)) != NULL)
else if (symbol >= STT_LOOS && symbol <= STT_HIOS)
snprintf (buf, len, "LOOS+%d", symbol - STT_LOOS);
and one gets then:
./src/readelf -s /home/marxin/Programming/testcases/a.out | grep strcmp
2: 0000000000000000 0 GNU_IFUNC GLOBAL DEFAULT UNDEF strcmp@GLIBC_2.2.5 (2)
@Mark: What do you think about such a change?
(In reply to Martin Liska from comment #1)
> - && (ident = elf_getident (ebl->elf, NULL)) != NULL
> - && ident[EI_OSABI] == ELFOSABI_LINUX)
> + && (ident = elf_getident (ebl->elf, NULL)) != NULL)
Patch approved, but I would suggest adding a comment referring back to this PR, just in case a future reader wonders why the OSABI field is not being checked as well.
The master branch has been updated by Martin Liska <email@example.com>:
Author: Martin Liska <firstname.lastname@example.org>
Date: Thu Nov 24 13:17:01 2022 +0100
readelf: Do not require EI_OSABI for IFUNC.
* readelf.c (get_symbol_type): Consider STT_GNU_IFUNC as
Sorry, I think this is wrong. You cannot assume anything about a field defined to be in the OSABI space if the OSABI field is not set. It doesn't matter that the tools have been lazy in not enforcing this correctly.
(In reply to Richard Earnshaw from comment #6)
> Sorry, I think this is wrong. You cannot assume anything about a field
> defined to be in the OSABI space if the OSABI field is not set. It doesn't
> matter that the tools have been lazy in not enforcing this correctly.
You are correct, standard should be followed. I created lld issue for that:
Reverted in ffbbab0b3a1000f862b6d4ce3d9a76ed14f08801 and thus closing as invalid.