[PATCH][GOLD] Treat R_ARM_PREL31 as a function call in Target_arm::Scan::get_reference_flags
Paul Brook
paul@codesourcery.com
Fri Dec 10 15:39:00 GMT 2010
> "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
More information about the Binutils
mailing list