public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <oliva@adacore.com>
To: binutils@sourceware.org
Subject: avoiding undesirable undef[weak] syms after relocatable linking
Date: Fri, 05 Apr 2024 12:38:06 -0300	[thread overview]
Message-ID: <orfrvz7rc1.fsf@lxoliva.fsfla.org> (raw)


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

             reply	other threads:[~2024-04-05 15:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-05 15:38 Alexandre Oliva [this message]
2024-04-12  9:01 ` Nick Clifton
2024-04-13 10:15   ` Alexandre Oliva
2024-04-13 13:52     ` H.J. Lu
2024-04-13 14:46       ` H.J. Lu
2024-04-16  6:00       ` Alexandre Oliva
2024-04-16 11:55         ` H.J. Lu
2024-04-18  7:43           ` Alexandre Oliva

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=orfrvz7rc1.fsf@lxoliva.fsfla.org \
    --to=oliva@adacore.com \
    --cc=binutils@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).