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

[Richard Sandiford <richard dot sandiford at linaro dot org>]

"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