This is the mail archive of the 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: Problem with string merging and PC relative relocations

> From: Andreas Jaeger <>
> Date: Mon, 11 Feb 2002 18:27:13 +0100

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

Remove the warning.  Relocs can have arbitrary offsets, and just
because a reloc is to an address that doesn't appear to be inside the
section doesn't mean that the final reference is to that address.

For instance, given

int foo(int b)
  return "abcdef"[b-10];

it's perfectly valid to generate a reloc to the address of the string
minus 10, and in fact this is the most efficient code.

- Geoffrey Keating <> <>

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