This is the mail archive of the binutils@sources.redhat.com 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: [RFA] ARM OABI - pc-relative relocations


Zack Weinberg (zack@codesourcery.com):

> My experience is that their linker and loader do honor the instruction
> addend if it's nonzero, but their assembler doesn't ever set it to
> anything but zero.  So setting it to zero in the assembler, and
> ignoring it in the linker, is good enough for interoperability.  I

I don't think it is always true. For example, if I compile the
program I sent with the Tornado tools(*), with dwarf2 debug info, I
have an interesting result for the reloc of .debug_info:

vienna% readelfarm -r r_dw2.o
Relocation section '.rela.debug_info' at offset 0x6e8 contains 8 entries:
  Offset    Info  Type            Symbol's Value  Symbol's Name          Addend
[...]
  00000010  00202 R_ARM_ABS32           00000000  .text                     + 0
[...]

vienna% objdumparm  -s -j .debug_info  r_dw2.o
Contents of section .debug_info:
 0000 d4000000 02000000 00000401 00000000  ................
 0010 38000000 00000000 722e6300 2f636172  8.......r.c./car
      ^^^^^^^^
There is an implicit addend (And it is not just junk, it is the
DW_AT_high_pc of the DW_TAG_compile_unit, it can't be 0)

(*) I am using Tornado 2.2/VxWorks 5.5 for SA/XScale

> agree that honoring the letter of the old-ABI spec might be desirable,
> but I don't have time to figure out how at the moment, or how to make
> that play nice with the revision to the spec that eliminates this
> quirk.

Your patch follows the old-ABI spec, as the src_masks of the relocs
are not null :-)

-- 
Jerome


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