[Bug ld/31652] New: weak def in discarded comdat section becomes unreferenced undefweak with ld -r

[aoliva at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31652

            Bug ID: 31652
           Summary: weak def in discarded comdat section becomes
                    unreferenced undefweak with ld -r
           Product: binutils
           Version: 2.43 (HEAD)
               URL: https://sourceware.org/pipermail/binutils/2024-April/1
                    33602.html
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: aoliva at sourceware dot org
  Target Milestone: ---

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

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
.global _start
.set _start,foo

And here's how to trigger the problem:
(simplified from the emails, dropping the unnecessary archive and linking the
object file in it directly; the asm sources were also simplified, dropping bits
that were meant to pull t.o from the archive)

gas/as-new t.s -o t.o && gas/as-new m.s -o m.o && ld/ld-new m.o t.o -o m -r &&
binutils/nm-new m | grep bar
                 w bar

Tested with 2.38, 2.42, and 2.42.50.20240413, targeting x86_64-linux-gnu, and
also 2.42 targeting multiple vxworks7r2 targets.

This is probably expected behavior: the weakly-defined symbol in t.o 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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.