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

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

[Doug Kwan (關振德)]

[-- Attachment #1: Type: text/plain, Size: 502 bytes --]

Hi,

    This patch fixes a number of test breakage in which R_ARM_PREL31
relocations point to weak symbols of personality routines in ARM
unwind tables.  The existing code does not general PLTs for references
from R_ARM_PREL31 and ultimately it causes tests to crash on ARM.  The
patch was tested on armv7l-linux-gnueabi in qemu.

-Doug

2010-12-07  Doug Kwan  <dougkwan@google.com>

        * arm.cc (Target_arm::Scan::get_reference_flags): Treat R_ARM_PREL31
        like function call relocations.

[-- Attachment #2: patch-prel31.txt --]
[-- Type: text/plain, Size: 1032 bytes --]

Index: gold/arm.cc
===================================================================
RCS file: /cvs/src/src/gold/arm.cc,v
retrieving revision 1.128
diff -u -u -p -r1.128 arm.cc
--- gold/arm.cc	11 Nov 2010 10:43:30 -0000	1.128
+++ gold/arm.cc	8 Dec 2010 02:07:24 -0000
@@ -7646,7 +7646,6 @@ Target_arm<big_endian>::Scan::get_refere
     case elfcpp::R_ARM_THM_MOVW_BREL:
     case elfcpp::R_ARM_GOTOFF32:
     case elfcpp::R_ARM_GOTOFF12:
-    case elfcpp::R_ARM_PREL31:
     case elfcpp::R_ARM_SBREL31:
       return Symbol::RELATIVE_REF;
 
@@ -7659,6 +7658,10 @@ Target_arm<big_endian>::Scan::get_refere
     case elfcpp::R_ARM_THM_JUMP6:
     case elfcpp::R_ARM_THM_JUMP11:
     case elfcpp::R_ARM_THM_JUMP8:
+    // R_ARM_PREL31 is not used to relocate call/jump instructions but
+    // in unwind tables. It may point to functions via PLTs.
+    // So we treat it like call/jump relocations above.
+    case elfcpp::R_ARM_PREL31:
       return Symbol::FUNCTION_CALL | Symbol::RELATIVE_REF;
 
     case elfcpp::R_ARM_GOT_BREL:

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

[Ian Lance Taylor]

"Doug Kwan (關振德)" <dougkwan@google.com> writes:

> 2010-12-07  Doug Kwan  <dougkwan@google.com>
>
>         * arm.cc (Target_arm::Scan::get_reference_flags): Treat R_ARM_PREL31
>         like function call relocations.

This is OK.

Thanks.

Ian

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

[Richard Sandiford]

"Doug Kwan (關振德)" <dougkwan@google.com> writes:
> Index: gold/arm.cc
> ===================================================================
> RCS file: /cvs/src/src/gold/arm.cc,v
> retrieving revision 1.128
> diff -u -u -p -r1.128 arm.cc
> --- gold/arm.cc	11 Nov 2010 10:43:30 -0000	1.128
> +++ gold/arm.cc	8 Dec 2010 02:07:24 -0000
> @@ -7646,7 +7646,6 @@ Target_arm<big_endian>::Scan::get_refere
>      case elfcpp::R_ARM_THM_MOVW_BREL:
>      case elfcpp::R_ARM_GOTOFF32:
>      case elfcpp::R_ARM_GOTOFF12:
> -    case elfcpp::R_ARM_PREL31:
>      case elfcpp::R_ARM_SBREL31:
>        return Symbol::RELATIVE_REF;
>  
> @@ -7659,6 +7658,10 @@ Target_arm<big_endian>::Scan::get_refere
>      case elfcpp::R_ARM_THM_JUMP6:
>      case elfcpp::R_ARM_THM_JUMP11:
>      case elfcpp::R_ARM_THM_JUMP8:
> +    // R_ARM_PREL31 is not used to relocate call/jump instructions but
> +    // in unwind tables. It may point to functions via PLTs.
> +    // So we treat it like call/jump relocations above.
> +    case elfcpp::R_ARM_PREL31:
>        return Symbol::FUNCTION_CALL | Symbol::RELATIVE_REF;
>  
>      case elfcpp::R_ARM_GOT_BREL:

Hmm, I see this matches BFD's behaviour, but it isn't what I'd expect
from the EABI.  Specifically, FUNCTION_CALL is defined as:

    // A reference that can always be treated as a function call.
    FUNCTION_CALL = 8

and it isn't clear (to me) from the EABI that _all_ R_ARM_PREL31s can
be treated as function calls.  The EABI says that R_ARM_PREL31 is a
general static data relocation, like R_ARM_ABS*, instead.

Richard

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

[Doug Kwan (關振德)]

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.

-Doug

On Wed, Dec 8, 2010 at 7:01 AM, Richard Sandiford
<richard.sandiford@linaro.org> wrote:
> "Doug Kwan (關振德)" <dougkwan@google.com> writes:
>> Index: gold/arm.cc
>> ===================================================================
>> RCS file: /cvs/src/src/gold/arm.cc,v
>> retrieving revision 1.128
>> diff -u -u -p -r1.128 arm.cc
>> --- gold/arm.cc       11 Nov 2010 10:43:30 -0000      1.128
>> +++ gold/arm.cc       8 Dec 2010 02:07:24 -0000
>> @@ -7646,7 +7646,6 @@ Target_arm<big_endian>::Scan::get_refere
>>      case elfcpp::R_ARM_THM_MOVW_BREL:
>>      case elfcpp::R_ARM_GOTOFF32:
>>      case elfcpp::R_ARM_GOTOFF12:
>> -    case elfcpp::R_ARM_PREL31:
>>      case elfcpp::R_ARM_SBREL31:
>>        return Symbol::RELATIVE_REF;
>>
>> @@ -7659,6 +7658,10 @@ Target_arm<big_endian>::Scan::get_refere
>>      case elfcpp::R_ARM_THM_JUMP6:
>>      case elfcpp::R_ARM_THM_JUMP11:
>>      case elfcpp::R_ARM_THM_JUMP8:
>> +    // R_ARM_PREL31 is not used to relocate call/jump instructions but
>> +    // in unwind tables. It may point to functions via PLTs.
>> +    // So we treat it like call/jump relocations above.
>> +    case elfcpp::R_ARM_PREL31:
>>        return Symbol::FUNCTION_CALL | Symbol::RELATIVE_REF;
>>
>>      case elfcpp::R_ARM_GOT_BREL:
>
> Hmm, I see this matches BFD's behaviour, but it isn't what I'd expect
> from the EABI.  Specifically, FUNCTION_CALL is defined as:
>
>    // A reference that can always be treated as a function call.
>    FUNCTION_CALL = 8
>
> and it isn't clear (to me) from the EABI that _all_ R_ARM_PREL31s can
> be treated as function calls.  The EABI says that R_ARM_PREL31 is a
> general static data relocation, like R_ARM_ABS*, instead.
>
> Richard
>

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

[Richard Sandiford]

"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

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

[Doug Kwan (關振德)]

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
>

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

[Paul Brook]

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

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

[Richard Sandiford]

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