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

[Paul Brook <paul at codesourcery dot com>]

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

Paul