https://sourceware.org/bugzilla/show_bug.cgi?id=33684
Bug ID: 33684
Summary: GNU ld and objcopy handling of section symbols on x86
breaks Solaris symbol sort sections
Product: binutils
Version: 2.45
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: ali_swbugzilla at emvision dot com
Target Milestone: ---
In September, an old fixed objcopy bug specific to Solaris was reopened.
19938 - objcopy breaks sh_link and sh_info of SHT_SUNW_LDYNSYM
and SHT_SUNW_symsort sections
https://sourceware.org/bugzilla/show_bug.cgi?id=19938
I don't think it should have been reopened, and that it should be
re-closed now, as the problem it reports was fixed years ago, and
appears to remain fixed. However, that discussion revealed a new
and different issue, one that also involves sh_link and symbol sort
sections. I am filing this bug for that.
This appears to be x86 specific. As I'll show below, we don't see
a problem when using gcc or gld on sparc. It seems that the x86 GNU
ld (gld on Solaris) does not produce section symbols in the objects
it produces, and that when x86 objcopy (gobjcopy on Solaris) encounters
an object that does have section symbols, it rewrites the symbol
table to drop them, thereby changing the indexes of the remaining
symbols.
I don't understand why gld does not produce these symbols, and believe
it to be a bug. More importantly though, for objcopy to strip them by
default seems like a bug. And on Solaris, when the Solaris ld is used,
which does create section symbols, this stripping damages the symbol
sort sections that are associated to the .symtab with the sh_link section
header field.
All of what follows is run on Solaris. Rainer Orth maintains modern
Solaris systems in the gcc test farm that are available for those that
want to reproduce these results.
A simple hello world program can be used to demonstrate this issue.
Note that elfdump performs a lot of diagnostic checks, and sends errors
to stderr, so redirecting stdout to /dev/null is a standard idiom for
sanity checking. Also, objcopy on Solaris is named gobjcopy. In each
case, a high level interpretation of the results is given following
the example.
Using Solaris ld, on x86:
% gcc -fpic -c hello.c
% ld -G hello.o -o foo.so
% elfdump foo.so > /dev/null
% gobjcopy foo.so foo_copy.so
% elfdump foo_copy.so > /dev/null
foo_copy.so: .symtab: bad symbol index: 25
foo_copy.so: .symtab: bad symbol index: 31
foo_copy.so: .symtab: bad symbol index: 32
... 10 similar error lines elided ...
foo_copy.so: .symtab: bad symbol index: 32
% elfdump -sN.symtab foo.so | grep SECT | wc -l
23
% elfdump -sN.symtab foo_copy.so | grep SECT | wc -l
0
Summary: On x86, the Solaris link-editor produces 23 section symbols
that objcopy strips, thereby breaking the symbol sort sections that
contain symbol table indexes.
Using GNU ld, on x86:
% gcc -fpic -c hello.c
% gld --shared hello.o -o foo.so
% elfdump foo.so > /dev/null
% gobjcopy foo.so foo_copy.so
% elfdump foo_copy.so > /dev/null
% elfdump -sN.symtab foo.so | grep SECT | wc -l
0
% elfdump -sN.symtab foo_copy.so | grep SECT | wc -l
0
Summary: On x86, the GNU link-editor (I think incorrectly) produces
no section symbols. As such objcopy does not rewrite the symbol table,
and all seems well, though some debuggers might want to see section
symbols. Solaris symbol sort sections are not supported by gld, and
so are not a factor.
Using Solaris ld, on sparc:
% gcc -fpic -c hello.c
% ld -G hello.o -o foo.so
% elfdump foo.so > /dev/null
% gobjcopy foo.so foo_copy.so
% elfdump foo_copy.so > /dev/null
% elfdump -sN.symtab foo.so | grep SECT | wc -l
21
% elfdump -sN.symtab foo_copy.so | grep SECT | wc -l
21
Summary: On sparc, the Solaris link-editor produces 21 section
symbols which objcopy correctly leaves alone, thereby preserving the
symbol sort sections that contain symbol table indexes.
Using GNU ld, on x86:
% gcc -fpic -c hello.c
% gld --shared hello.o -o foo.so
% elfdump foo.so > /dev/null
% gobjcopy foo.so foo_copy.so
% elfdump foo_copy.so > /dev/null
% elfdump -sN.symtab foo.so | grep SECT | wc -l
12
% elfdump -sN.symtab foo_copy.so | grep SECT | wc -l
12
Summary: On sparc, the GNU link-editor (correctly) produces 21
section symbols, which objcopy correctly leaves alone. This is
how I would expect it to work, noting again that Solaris symbol
sort sections are not supported by gld, and so are not a factor.
Although it seems to be as if both gld and objcopy have section symbol
related bugs on x86, I wonder if there is a common root for both in
binutils. The fact that it's done differently (correctly) on sparc
is also interesting, because these are generic ELF features that one
would expect the work the same way everywhere.
I will follow this initial note with a more detailed analysis
showing how the symbol sort sections are harmed.
Thanks, as always, for your help.
- Ali
--
You are receiving this mail because:
You are on the CC list for the bug.
