Bug 29718 - readelf prints out "<OS specific>: 10" instead of "IFUNC"
Summary: readelf prints out "<OS specific>: 10" instead of "IFUNC"
Status: RESOLVED INVALID
Alias: None
Product: binutils
Classification: Unclassified
Component: binutils (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-10-24 02:32 UTC by Rui Ueyama
Modified: 2022-11-25 13:01 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed: 2022-11-25 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rui Ueyama 2022-10-24 02:32:08 UTC
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?
Comment 1 Martin Liska 2022-10-25 06:25:59 UTC
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
--- a/libebl/eblsymboltypename.c
+++ b/libebl/eblsymboltypename.c
@@ -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)
 	    return "GNU_IFUNC";
 	  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?
Comment 2 Nick Clifton 2022-10-31 10:31:49 UTC
(In reply to Martin Liska from comment #1)

Hi Martin,

> -		   && (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.

Cheers
  Nick
Comment 3 Sourceware Commits 2022-11-24 12:18:55 UTC
The master branch has been updated by Martin Liska <marxin@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ffbbab0b3a1000f862b6d4ce3d9a76ed14f08801

commit ffbbab0b3a1000f862b6d4ce3d9a76ed14f08801
Author: Martin Liska <mliska@suse.cz>
Date:   Thu Nov 24 13:17:01 2022 +0100

    readelf: Do not require EI_OSABI for IFUNC.
    
            PR 29718
    
    binutils/ChangeLog:
    
            * readelf.c (get_symbol_type): Consider STT_GNU_IFUNC as
            reserved name.
Comment 4 Martin Liska 2022-11-24 12:19:11 UTC
Original issue:
https://github.com/rui314/mold/issues/805
Comment 5 Martin Liska 2022-11-24 12:19:23 UTC
Fixed now.
Comment 6 Richard Earnshaw 2022-11-25 11:04:53 UTC
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.
Comment 7 Martin Liska 2022-11-25 12:59:55 UTC
(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:
https://github.com/llvm/llvm-project/issues/59199
Comment 8 Martin Liska 2022-11-25 13:01:24 UTC
Reverted in ffbbab0b3a1000f862b6d4ce3d9a76ed14f08801 and thus closing as invalid.