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]

Problem with string merging and PC relative relocations



Andreas Schwab and myself looked closer into this message on x86-64:

x86_64-unknown-linux-ld: /abuild/aj/build/elf/librtld.os: access beyond end of merged section (-4 + 0)

We've located this relocation in dl-cache.os (part of glibc):
 216:   48 8d 3d 00 00 00 00    lea    0(%rip),%rdi        # 21d <_dl_load_cache_lookup+0x12d>
                        219: R_X86_64_PC32      .rodata.str1.1+0xfffffffffffffffc

The problem is the PC-relative addressing here.  The offset
compensates for the fact that the addressing is relative to the *next*
instruction.  So, it is not really an offset into the string section -
and should not be treated as such.

Looking at _bfd_elf_rela_local_sym in elf.c and
_bfd_merged_section_offset in merge.c, PC relative relocations seem
not to be handled at all.  We encountered this with a negative offset
but with short strings and a positive offset the same problem could
occur on other archs using PC relative addressing for this.

The final value of the relocation is - as expected - wrong, the lea
points to a different string.

Has anybody an idea how to fix this?

If anybody likes to reproduce it: Cross-compile glibc 2.2.5 with GCC
3.1 CVS and current binutils,

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj


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