Re: [PATCH][GOLD] Treat R_ARM_PREL31 as a function call in Target_arm::Scan::get_reference_flags

[Richard Sandiford <rdsandiford at googlemail dot com>]

Paul Brook <paul@codesourcery.com> writes:
>> "Doug Kwan (éæå)" <dougkwan@google.com> writes:
>> > An R_ARM_PREL31 relocation can point to a personality routine that is
>> > called during unwinding.  If the personality routine is not in the
>> > output, we need to generate a PLT.
>> 
>> Sure, I understand that, but that wasn't really my question.  Is it true
>> that _all_ R_ARM_PREL31 references (not _just_ those in the unwind
>> sections) can be treated as function calls?  That is, is it really true
>> that the correct way of handling references to undefined symbols in
>> shared libraries is to generate a PLT rather than attempt to generate a
>> dynamic relocation (and in this case, I assume, fail to do so with an
>> error)?  Do R_ARM_PREL31 relocations never need the canonical function
>> address?
>
> I think this is a flaw in the EABI.
>
> Specifically the list of relocations where call veneers (including but
> not limited to PLT stubs) are allowed does not include R_ARM_PREL31.
>
> However all known uses of R_ARM_PREL31 are in contexts where the
> canonical address is not required, and some OS APIs require use of
> these relocations in readonly segments. i.e. they must be resolved at
> static link time.

Ah, great, thanks for info.  And thanks too to Doug for his reply.
I'm happy now. :-)

Also, thanks Doug for cleaning up after me.

Richard