This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PR 18167, Relax PR 15228 protected visibility restriction

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 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.


Alan Modra
Australia Development Lab, IBM

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]