Bug 29718

Summary:	readelf prints out "<OS specific>: 10" instead of "IFUNC"
Product:	binutils	Reporter:	Rui Ueyama <rui314>
Component:	binutils	Assignee:	Not yet assigned to anyone <unassigned>
Status:	RESOLVED INVALID
Severity:	normal	CC:	mark, martin.liska, nickc, rearnsha
Priority:	P2
Version:	unspecified
Target Milestone:	---
See Also:	https://github.com/llvm/llvm-project/issues/59199
Host:		Target:
Build:		Last reconfirmed:	2022-11-25 00:00:00

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.