From: Michael Matz <matz@suse.de>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: Carlos O'Donell <carlos@redhat.com>,
Alan Modra <amodra@gmail.com>,
gnu-gabi@sourceware.org
Subject: Re: Specify how undefined weak symbol should be resolved in executable
Date: Fri, 01 Jan 2016 00:00:00 -0000 [thread overview]
Message-ID: <alpine.LSU.2.20.1602241801070.20277@wotan.suse.de> (raw)
In-Reply-To: <CAMe9rOo24H0_Rw0fQAzW+bs+xQvjT+vjqS-X10JyovowcLuhBA@mail.gmail.com>
Hi,
On Wed, 24 Feb 2016, H.J. Lu wrote:
> >> I was saying as far as ld was concerned, weak defined and non-weak
> >> defined dynamic symbols would be treated equally at run-time. Do you
> >> agree with me?
> >
> > I at least don't. The difference is that a defined weak symbol (at
> > link edit time) might become undefined at runtime. A defined non-weak
> > symbol can't. So they have to be handled differently.
> >
>
> How?
Like right now (mostly)? Resolution of weak symbols needs to be deferred
to the dynamic linker, in particular they mustn't be resolved (to either
zero or an address) at link edit time. There's one case where weak
symbols can be resolved early: if at link edit time the executable itself
provides a definition of 'foo' then weak references can be directly
resolved to that one (because at runtime of that exectuable there's no
possibility to not have this symbol defined).
To not do that (i.e. resolve them always at link edit time) breaks various
current uses of weak symbols. We could do that of course, but I don't
think that would be useful to users.
Ciao,
Michael.
next prev parent reply other threads:[~2016-02-24 17:08 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-01 0:00 H.J. Lu
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Michael Matz
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Michael Matz
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Alan Modra
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Michael Matz
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Michael Matz
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Alan Modra
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Alan Modra
2016-01-01 0:00 ` Carlos O'Donell
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Michael Matz
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Michael Matz [this message]
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Michael Matz
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Michael Matz
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Michael Matz
2016-01-01 0:00 ` Szabolcs Nagy
2016-01-01 0:00 ` Michael Matz
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` H.J. Lu
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=alpine.LSU.2.20.1602241801070.20277@wotan.suse.de \
--to=matz@suse.de \
--cc=amodra@gmail.com \
--cc=carlos@redhat.com \
--cc=gnu-gabi@sourceware.org \
--cc=hjl.tools@gmail.com \
/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).