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

[Richard Sandiford <richard dot sandiford at linaro dot org>]

Ian Lance Taylor <iant@google.com> writes:
> Richard Sandiford <richard.sandiford@linaro.org> writes:
>> Unfortunately, just removing:
>>
>>  ? ?if (this->is_weak_undefined())
>>  ? ? ?return true;
>>
>> regresses weak_plt on x86_64.  We rely completely on use_plt_offset() to
>> determine whether a relocation uses a PLT, so removing the check means
>> that even:
>>
>> 	call    foo@PLT
>>
>> won't use a PLT for a weak undefined foo in executables.  (Recall that
>> BFD LD does use a PLT in this case, and rightly so.)
>>
>> What I found a little confusing is that use_plt_offset() unconditionally
>> passes FUNCTION_CALL to needs_dynamic_reloc(), even though most calls to
>> use_plt_offset() are made for all relocation types, not just branch/call
>> relocations.  Is FUNCTION_CALL supposed to mean something else in this
>> context?
>>
>> Perhaps we should turn the use_plt_offset() argument into the same
>> Reference_flags set as needs_dynamic_reloc(), then get the callers of
>> use_plt_offset() to set FUNCTION_CALL only for branch/call relocs.
>> That would let us restrict:
>>
>>  ? ?if (this->is_weak_undefined())
>>  ? ? ?return true;
>>
>> to cases where FUNCTION_CALL is set.  Unfortunately, this will touch
>> all backends, so I thought I'd better ask for comments before coding it up.
>
> use_plt_offset is only meaningful when there actually is a PLT.  A
> backend like i386.cc sets FUNCTION_CALL when calling needs_dynamic_reloc
> for any symbol with type STT_FUNC.  Only STT_FUNC symbols get PLT
> offsets.  So at least for the i386 backend it will always be appropriate
> to pass FUNCTION_CALL from use_plt_offset to needs_dynamic_reloc.  There
> is no case in which the flag should not be set.
>
> The ARM backend does not appear to ever set FUNCTION_CALL when calling
> needs_dynamic_reloc.  I'm not sure why.
>
> In other words, FUNCTION_CALL isn't used to mean a relocation which is a
> function call.  It means a symbol which is a function.  It should
> probably be renamed to IS_FUNCTION.  Or just omitted, and
> needs_dynamic_reloc can check the symbol type itself.

Yeah, I think that would be better.  We probably then do need
a new flag to mean what it sounds like FUNCTION_CALL should mean:
that the reloc type is used for function calls (or something a bit
looser, as described below).

> It seems to me that the distinguishing characteristic of "foo@PLT" is
> not that it is a function call, it is that the relocation specifically
> requires the PLT.  I suspect that the right thing to do here is to
> always use the use the PLT offset, if there is one, for R_386_PLT32.

Well, the problem is that Thumb doesn't have separate relocs for
non-@PLT and @PLT function calls.  (ARM itself only has it with a
legacy relocation, R_ARM_PLT32.)

On targets like x86_64 that _do_ have this distinction, we've
already honoured that distinction when deciding whether to create
a PLT in the first place.  Is there actually any harm in resolving
a R_X86_64_PC32 to a PLT if a PLT had already been created for
other reasons?  E.g. for:

	call	foo
	call	foo@PLT

That said, BFD LD doesn't resolve R_X86_64_PC32 to a PLT even if
one exists, so if we're trying to be compatible, I suppose the
flag would have to mean "a potential PLT function call".  The flag
would be set for all function call relocs on ARM, but just the PLT
ones on targets like x86.

Richard