Re: GOLD handling of weak symbols (including x86 vs. ARM)

[Ian Lance Taylor <iant at google dot com>]

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

Either way, we need to use a dynamic reloc when not making a function
call.  So the question here is: why did that not happen?

In the i386 case, "call foo@PLT" seems to me to clearly indicate a call
to the PLT entry, so if we call the PLT entry then it seems to me that
the right thing is happening.

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.

Ian