This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: PR 18167, Relax PR 15228 protected visibility restriction
- From: Alan Modra <amodra at gmail dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>, Pedro Alves <palves at redhat dot com>, Binutils <binutils at sourceware dot org>
- Date: Mon, 30 Mar 2015 23:37:01 +1030
- Subject: Re: PR 18167, Relax PR 15228 protected visibility restriction
- Authentication-results: sourceware.org; auth=none
- References: <20150327054327 dot GB26234 at bubble dot grove dot modra dot org> <551531AA dot 1060006 at redhat dot com> <20150327122941 dot GC26234 at bubble dot grove dot modra dot org> <55158778 dot 8050009 at redhat dot com> <CAMe9rOrZB+kuDd-Z0hx-EMiZO=c2tG3J7gQH1JpNe_gHGSUBKA at mail dot gmail dot com> <20150328124741 dot GG26234 at bubble dot grove dot modra dot org>
On Sat, Mar 28, 2015 at 11:17:41PM +1030, Alan Modra wrote:
> On Fri, Mar 27, 2015 at 09:40:08AM -0700, H.J. Lu wrote:
> > There is no backward compatibility to speak with since protected
> > data symbol never worked before.
>
> That isn't entirely true. It is true that they didn't always work as
> designed when a non-PIC executable referenced a protected variable in
> a shared library, but they do work as designed where an executable has
> a definition of the variable. In that case the executable uses its
> own variable, and the shared library uses its own protected variable.
> I believe your change to gcc would break this particular usage of
> protected variables since the shared library would use the
> executable's variable, if an older ld.so resolved the symbols. So
> there needs to be some mechanism to avoid this regression.
Another option is to edit non-PIC sequences accessing protected
visibility variables to PIC, which gives you a solution implemented
entirely in the linker. I've done this for powerpc. (powerpc64
isn't affected by the fundamental incompatiblity between protected
visibility variables and .dynbss, because powerpc64 gcc always
generates PIC.)
This relocatable object file:
00000000 <foo>:
0: 3c 60 00 00 lis r3,0
2: R_PPC_ADDR16_HA x
4: 80 63 00 00 lwz r3,0(r3)
6: R_PPC_ADDR16_LO x
8: 4e 80 00 20 blr
linked against a shared library defining a protected visibility "x"
results in:
018001d0 <foo>:
18001d0: 48 00 00 0c b 18001dc <foo+0xc>
18001d4: 80 63 00 00 lwz r3,0(r3)
18001d8: 4e 80 00 20 blr
18001dc: 3c 60 01 81 lis r3,385
18001e0: 80 63 02 68 lwz r3,616(r3)
18001e4: 4b ff ff f0 b 18001d4 <foo+0x4>
and a GOT entry with dynamic reloc
01810268 00000114 R_PPC_GLOB_DAT 00000000 x + 0
Quite obviously the two extra branches are not a desirable feature,
but the linker can't assume the GOT pointer register is set up and so
needs a two insn sequence to load from the GOT.
Testing..
--
Alan Modra
Australia Development Lab, IBM