This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: GOLD handling of weak symbols (including x86 vs. ARM)
Ian Lance Taylor <iant@google.com> writes:
> Richard Sandiford <richard.sandiford@linaro.org> writes:
>> So, in the corresponding code for Thumb:
>>
>> .global main
>> .thumb
>> .thumb_func
>> .type main, %function
>> main:
>> .fnstart
>> .LFB0:
>> @ args = 0, pretend = 0, frame = 0
>> @ frame_needed = 0, uses_anonymous_args = 0
>> push {r3, lr}
>> .save {r3, lr}
>> movw r3, #:lower16:foo
>> movt r3, #:upper16:foo
>> cbz r3, .L2
>> bl foo
>> .L2:
>> movs r0, #0
>> pop {r3, pc}
>> .fnend
>> .size main, .-main
>> .weak foo
>>
>> GOLD effectively handles "bl foo" in the same way that it would handle
>> "call foo@PLT" on x86. It creates a PLT for foo, then resolves the
>> absolute relocations to the PLT rather than 0.
>
> When making a function call to a weak undefined symbol, if there is no
> dynamic reloc, then the linker must generate a call to the PLT entry.
> If we don't do that, there is no way to handle the case in which the
> symbol is defined by a shared library.
Right. I should have been clearer, sorry. The mail wasn't questioning
the behaviour of the _call_ reloc in either the x86 or Thumb case;
the treatment of that reloc is the same for BFD LD and GOLD, and is
what I expected. The question was whether the absolute text relocation
("movl $foo..." for x86 or the upper/lower relocs for Thumb) should
resolve to 0 even if the call reloc triggers the creation of a PLT.
The absolute text relocs are resolved statically by both linkers and
on both targets. BFD LD resolves them to 0 even if there is a PLT,
but GOLD resolves them to the PLT if there is one. This means that
taking the address of a weak undefined symbol returns a nonzero value
on both x86 (when using @PLT on the call) and Thumb (regardless of
whether you use @PLT on the call).
(Of course, if the address is loaded from the GOT, it gets a dynamic
reloc with both linkers.)
> So I think we have two alternatives: 1) use the PLT entry for a
> function call and use a dynamic reloc when not making a function call;
> 2) always use a dynamic reloc.
But this means putting a dynamic reloc in the text section and...
> If I understand the ARM case, you are asking about the :lower16:foo and
> :upper16:foo operands, not the bl. You want those operands to get
> dynamic relocs. Why is that not happening? Perhaps we simply need to
> add R_ARM_THM_MOVW_ABS_NC and R_ARM_THM_MOVT_ABS to the switch in
> reloc_is_non_pic in arm.cc.
...unfortunately, in the case of Thumb, you're not allowed to have dynamic
R_ARM_THM_MOV*_ABS* reloctions. They have to be resolved statically.
Richard