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: [PATCH 1/1] gold: Avoid duplicate PLT stub symbols on PowerPC

On 19 Jun 2017, at 04:13, Alan Modra <> wrote:
> On Mon, Jun 19, 2017 at 12:34:42PM +0930, Alan Modra wrote:
>> On Sun, Jun 18, 2017 at 10:58:03PM +0100, James Clarke wrote:
>>> If two objects are compiled with -fPIC or -fPIE and call the same
>>> function, two different PLT entries are created, one for each object,
>> I'd be surprised if that was so when using your simple testcase, and
>> testing here verifies it.  There is a situation where this can occur:
>> In a very large binary it may be necessary to create multiple stubs to
>> call a given function, because calls are so far apart that a single
>> stub cannot be reached by a "bl" instruction.  However, that case
>> ought to be covered by this->uniq_ being different for each
>> stub_table.  So I'm not sure how you are getting the failure.
> Incidentally, you can provoke multiple stubs with the small testcase
> by using a ridiculously small --stub-group-size=64 (and ignore all the
> warnings about section "exceeds group size".  If I do that, I see
> nm printf | grep puts
> 0000000000000840 t 00000004.plt_call.puts
> 00000000000008a0 t 00000005.plt_call.puts
>                 U puts
> objdump also shows the two plt call stubs for puts.
>>> but the same stub symbol name is used for both. Therefore let's make
>>> the names unique by incorporating the object's uniq_ value where
>>> necessary.
>>> gold/
>>> 	* (Stub_table::define_stub_syms): Include object's uniq_ value
>>> 	when set for non-local symbols as well.
>> This won't work.  object_ isn't set for ppc64 globals.  See the
>> Plt_stub_ent constructors.

It's because, with -fPIC/-fPIE, one GOT is used per object file (.got2), so
each object file needs its own PLT stubs referring to the right GOT, which is
indicated by the addend being the magic 0x8000. You can see in one of the
Plt_stub_ent constructors that the object_ field is non-NULL for globals only
in this case. This means the same stub table ends up with multiple stub entries
for a given global function. This is only an issue on 32-bit PowerPC as 64-bit
PowerPC doesn't have this weirdness, and your multiple stub tables case *is*
covered correctly as you saw yourself.


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