[PATCH][GOLD] Treat R_ARM_PREL31 as a function call in Target_arm::Scan::get_reference_flags
Richard Sandiford
rdsandiford@googlemail.com
Fri Dec 10 17:50:00 GMT 2010
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
More information about the Binutils
mailing list