This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ARM] Relocations against STN_UNDEF


Hello!

On 2010-09-24 14:52, Richard Henderson wrote:
> On 09/24/2010 04:25 AM, Thomas Schwinge wrote:
>>     $ cat < ~/sgxx/issue8612/bl_ABS.s
>>             bl 0x10000
>>     $ "$PWD"_install/bin/*-as -o bl_ABS.o ~/sgxx/issue8612/bl_ABS.s
>>     $ "$PWD"_install/bin/*-readelf -r bl_ABS.o 
>>     
>>     Relocation section '.rel.text' at offset 0x25c contains 1 entries:
>>      Offset     Info    Type            Sym.Value  Sym. Name
>>     00000000  0000001c R_ARM_CALL       
>
> Err, why isn't this relocation against (the section symbol for) SHN_ABS
> plus the 0x10000 offset?

Uhm, as I quoted the standard in my message:

>> The ELF standard says that STN_UNDEF (symbol index zero, the undefined
>> symbol index) is to be marked as SHN_UNDEF, undefined symbol.  There is
>> one exception however: during relocations processing, a relocation
>> against STN_UNDEF shall be treated as a symbol value of zero.

Doesn't this mandate that during relocations processing, a relocation
against STN_UNDEF is equivalent to a new symbol as proposed by you, that
is: for STN_UNDEF, SHN_UNDEF is turned into SHN_ABS (value zero) during
relocations processing?


Regards,
 Thomas

Attachment: pgp00000.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]