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.1602231608470.20277@wotan.suse.de> (raw)
In-Reply-To: <CAMe9rOoSdG1M4K0k=Y3P+C7FSbqiqMdgPk4HoG1Fdqm-EtMddA@mail.gmail.com>
Hi,
On Tue, 23 Feb 2016, H.J. Lu wrote:
> > 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).
>
> This "feature" never worked on x86 for non-PIC input.
True (and that's exactly the difference between PIC and non-PIC).
> If we change ld now, all of a sudden, x86 binaris are marked with
> DT_TEXTREL. What we can do is to add a new linker command option, -z
> dynamic-undef-weak, and GCC passes it to ld only when compiler is
> changed to generate PIC-like code for address of all undefined symbol in
> text section.
Hmmnyeah, possible.
> > 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.
> >
> >
>
> I checked cc1plus and found:
>
> [hjl@gnu-6 5.3.1]$ readelf -sW cc1plus| grep WEAK | grep UND
Careful, that includes .symtab, not only .dynsym. These are the .dynsyms:
> 33: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_cond_signal@GLIBC_2.3.2 (3)
> 2924: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_cond_broadcast@GLIBC_2.3.2 (3)
> 4861: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_key_create
> 6330: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_getspecific
> 7205: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_mutex_unlock@GLIBC_2.2.5 (2)
> 7719: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_key_delete
> 9118: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __pthread_key_create
> 11985: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _Jv_RegisterClasses
> 12269: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_once
> 15201: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_mutex_lock@GLIBC_2.2.5 (2)
> 15794: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_cond_wait@GLIBC_2.3.2 (3)
> 18312: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_deregisterTMCloneTable
> 19108: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_setspecific
> 19649: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
> 19871: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_registerTMCloneTable
> 20107: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_cond_destroy@GLIBC_2.3.2 (3)
After here it's .symtab:
> 18570: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_cond_signal@@GLIBC_2.3.2
>
> Do you know how many of them lead to DT_TEXTREL?
I think all those not going via the PLT, hence looking at the relocs for
those symbols involved, ignoring JUMP_SLOT relocs will give you that. For
my cc1plus it's only this:
pthread_cancel
(of those that are undef-weak), and only one reference.
Ciao,
Michael.
next prev parent reply other threads:[~2016-02-23 15:16 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 ` 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
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 [this message]
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
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.1602231608470.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).