Re: Problem with string merging and PC relative relocations

[Geoff Keating <geoffk at geoffk dot org>]

> From: Andreas Jaeger <aj@suse.de>
> 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 <geoffk@geoffk.org> <geoffk@redhat.com>