avoiding undesirable undef[weak] syms after relocatable linking
Alexandre Oliva
oliva@adacore.com
Fri Apr 5 15:38:06 GMT 2024
The following, say t.s, is dystilled from libstdc++-v3's
floating_to_chars.o:
.section .text.foobar,"axG",@progbits,foo,comdat
.weak foo
.type foo,@function
foo:
# .dc.a undef
.size foo, . - foo
.weak bar
.set bar, foo
.text
.global baz
.type baz,@function
baz:
.dc.a foo
.size baz, . - baz
The weak definitions were originally implicit instantiations of
to_chars_i<unsigned int128_t>, and the aliases were originally meant for
abi compatibility because of changes in int128_t mangling.
The following, say m.s, is dystilled from a
libstdc++-v3/testsuite/std/time/clock/system/io.cc:
.section .text.foobar,"axG",@progbits,foo,comdat
.weak foo
.type foo,@function
foo:
.size foo, . - foo
.text
.global _start
.set _start,foo
.dc.a baz
And here's how to trigger the problem:
as t.s -o t.o && ar cr t.a t.o && ranlib t.a && as m.s -o m.o &&
ld m.o -o m -r && nm m | grep bar
w bar
This is probably expected behavior: the weakly-defined symbol in the
archive lives in a discarded section, so it decays to weak-undefined,
and it most likely goes unnoticed on systems that support undefweak.
If this were a final link, the bar symbol would be gone. So would the
undef symbol, if the reference to it in t.s were uncommented. But
because this is a relocatable link, both undefined symbols would remain.
Both of them are a problem for e.g. vxworks kernel modules, that never
undergo final linking, and whose loader rejects undefined symbols, even
weak ones, if they're not defined elsewhere.
I hoped --strip-discarded would get rid of undef, if not bar, but no
such luck. Could we arrange for it to do so, even in relocatable
linking? Or should we aim for another option to make -r (and -shared?)
linking behave more like final linking when it comes to discarding
unreferenced undefined symbols?
Thoughts? Recommendations?
Thanks in advance,
--
Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
More information about the Binutils
mailing list