From: Michael Matz <matz@suse.de>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: 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.1602231424140.20277@wotan.suse.de> (raw)
In-Reply-To: <CAMe9rOp1QHCyhV--Es9kSSBEqJs4ZGRGTqPeJ4mEYJsrymUmeQ@mail.gmail.com>
Hi,
On Tue, 23 Feb 2016, H.J. Lu wrote:
> On Mon, Feb 22, 2016 at 8:40 PM, Alan Modra <amodra@gmail.com> wrote:
> >
> > However, that might be a bad idea. Lots of C++ code uses weak symbols
> > for functions defined in header files, and other objects with vague
> > linkage. These result in weak definitions in eg. libstdc++.so. I'm
> > not sure how many executables take the address of such functions and
> > thus might become DT_TEXTREL.
>
> Most, if not all, of programs will have DT_TEXTREL on x86 if undefined
> weak symbols require dynamic relocations.
Hmm, that's less than ideal of course. Well, if the goal is to make PIC
and non-PIC the same, we could also go the opposite way: make PIC behave
like non-PIC, i.e. resolve weak symbols always at link editing time. That
of course would remove features (can't change libs at runtime anymore, if
they change in definedness of such a symbol).
Or, a third variant: change the compiler to emit PIC like code for taking
addresses of weak symbols also in generally non-PIC code, so we could
avoid TEXTREL.
I think the ideal solution would be that last one, change link editor now
to behave like with PIC code, and eventually fix the compiler to not have
to generate TEXTREL.
Note that the existence of DT_TEXTREL itself isn't that bad: only those
pages that actually contain relocations will be unshared, so for the
example of crtbegin.o it's only one page per process. In addition
crtbegin could of course always be PIC code, avoiding the issue.
I've looked at a normal c++ program (zypper) and the only weak undef
symbols are those from crtbegin. There are many other weak symbols, but
they are defined in the executable itself (it's mostly template
instantiations), so pose no problem.
Ciao,
Michael.
next prev parent reply other threads:[~2016-02-23 13:55 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 ` 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 ` 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
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 ` Michael Matz [this message]
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
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.1602231424140.20277@wotan.suse.de \
--to=matz@suse.de \
--cc=amodra@gmail.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).