Home Original page

Problem with string merging and PC relative relocations

Jakub Jelinek jakub@redhat.com
Mon Feb 11 10:12:00 GMT 2002 
On Mon, Feb 11, 2002 at 06:27:13PM +0100, Andreas Jaeger wrote:
> 
> 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.

This should not happen.
Only local relocs against SHF_MERGE section with zero addend should be
converted to STT_SECTION + addend.
This is what gas/write.c (adjust_reloc_syms):
        /* Never adjust a reloc against local symbol in a merge section
           with non-zero addend.  */
        if ((symsec->flags & SEC_MERGE) && fixp->fx_offset)
          {
            symbol_mark_used_in_reloc (fixp->fx_addsy);
            goto done;
          }

is for. If you modify the addend later in tc-*, you need to care about it in
your tc-* files.

	Jakub
More information about the Binutils mailing list