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

[Doug Kwan (éæå) <dougkwan at google dot com>]

Other non-calling R_ARM_PREL31 relocs point to ARM.extab entries or
functions whose unwinding behaviours are being described.  For those
use, we use section symbol + offset so gold can distinguish whether an
R_ARM_PREL31 needs a PLT or not.   We cannot generate a dynamic reloc
because there is no existing ARM dynamic reloc that can handle PREL31
encoding.  I guess you can generate R_ARM_PREL31 dynamic relocs but
dynamic linkers probably cannot handle them.   I cannot guarantee that
unwinding routines never need to compare function pointers.  In
practice, they just call the pointed functions.

-Doug

On Thu, Dec 9, 2010 at 1:13 PM, Richard Sandiford
<rdsandiford@googlemail.com> wrote:
> "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?
>
> It's a genuine question. ÂThe answer may well be "yes, R_ARM_PREL31 is
> effectively a call reloc". ÂI just wasn't sure from reading the EABI ELF
> spec.
>
> Richard
>