PR 18167, Relax PR 15228 protected visibility restriction
Alan Modra
amodra@gmail.com
Mon Mar 30 13:07:00 GMT 2015
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
More information about the Binutils
mailing list