This is the mail archive of the binutils@sourceware.org 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: 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


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