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