https://sourceware.org/bugzilla/show_bug.cgi?id=19938
--- Comment #33 from Ali Bahrami <ali_swbugzilla at emvision dot com> ---
(In reply to H.J. Lu from comment #32)
> > I'm confused by a couple of things. First, this bug was successfully
> > resolved back in 2016. But also, all Solaris executables or shared objects
> > with any Solaris-specific ABI features have set ELFOSABI_SOLARIS since 2009.
> > And in fact, the executable Rainer provided (in 2016) does have it:
> >
> > So what's the concern that's caused this to be reopened?
>
> Generic ELF objcopy doesn't know Solaris bits.
I appreciate that you're watching out for us, and if you say its broken, then I
have no reason to doubt that. What I do doubt is that this is because Solaris
objects claim to be generic, because they don't, and haven't for a very long
time.
So I tried Rainer's original example on my Solaris system, running the latest
bits:
% cc hello.c -o hello
% gobjcopy --version
GNU objcopy (GNU Binutils) 2.43.1
% gobjcopy hello hello.copy
% elfdump hello > /dev/null
% elfdump hello.copy > /dev/null
hello.copy: .symtab: bad symbol index: 66
hello.copy: .symtab: bad symbol index: 53
hello.copy: .symtab: bad symbol index: 72
hello.copy: .symtab: bad symbol index: 60
... many lines elided ...
hello.copy: .symtab: bad symbol index: 60
hello.copy: .symtab: bad symbol index: 43
So it does seem broken, but not in the way this bug reported. This bug was for
objcopy damaging the sh_link and sh_info fields in the section header of
SHT_SUNW_LDYNSYM and SHT_SUNW_symsort sections, and that's not what's happening
here. These errors are saying that the .symtab symbol indexes held in the
symbol sort sections are out of bounds. Here's what elfdump is reporting when
we don't send stdout to /dev/null:
Symbol Sort Section: .SUNW_symtabsort (.symtab)
index value size type bind oth ver shndx name
hello.copy: .symtab: bad symbol index: 66
hello.copy: .symtab: bad symbol index: 53
hello.copy: .symtab: bad symbol index: 72
[37] 0x8050968 0 FUNC GLOB D 0 UNDEF exit
hello.copy: .symtab: bad symbol index: 60
hello.copy: .symtab: bad symbol index: 58
While here's the output for the original hello:
Symbol Sort Section: .SUNW_symtabsort (.symtab)
index value size type bind oth ver shndx name
[66] 0x8050920 0x4 OBJT GLOB X 0 .rodata _lib_version
[53] 0x8050948 0 OBJT GLOB D 0 .plt
_PROCEDURE_LINKAGE_TABLE_
[72] 0x80509c0 0x86 FUNC GLOB X 0 .text _start
[37] 0x8050a48 0x11a FUNC LOCL H 0 .text __fsr
[60] 0x8050ba0 0x36 FUNC GLOB D 0 .text main
[58] 0x8050bd8 0x1b FUNC GLOB D 0 .init _init
That's weird, it seems that objcopy is taking liberties in rewriting the
.symtab. Here's the original section header:
Section Header[23]: sh_name: .symtab
sh_addr: 0 sh_flags: 0
sh_size: 0x4d0 sh_type: [ SHT_SYMTAB ]
sh_offset: 0xdf8 sh_entsize: 0x10 (77 entries)
sh_link: 24 sh_info: 50
sh_addralign: 0x4
and here's the objcopied replacement:
Section Header[32]: sh_name: .symtab
sh_addr: 0 sh_flags: 0
sh_size: 0x2b0 sh_type: [ SHT_SYMTAB ]
sh_offset: 0x1214 sh_entsize: 0x10 (43 entries)
sh_link: 33 sh_info: 16
sh_addralign: 0x4
77 entries became 43. In the interest of brevity, I won't show it here, but
objcopy has completely rewritten the .symtab without regard for any other
sections that might be referencing it. It's dropped 34 local symbols, and
changed the order of what's left. That breaks the sort sections that reference
it. I'm glad elfdump has that symbol boundary check, because I would not have
noticed this otherwise.
I think this bug should be closed, as the issue it describes was fixed years
ago, and that fix seems to still be in place. A new bug should be opened for
this new and different problem.
My opinion is that rewriting the symbol table is a basic misstep, and not
purely an OSABI concern. Even if objcopy knew about Solaris sort sections, and
was prepared to rewrite them as well, what makes anyone think that we want that
outcome? Even without sort sections, local symbols are important for debugging.
Unless I add some special options to request it, I would not expect a "copy" to
apply this sort of transformation.
--
You are receiving this mail because:
You are on the CC list for the bug.
