This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Problem with string merging and PC relative relocations
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Andreas Jaeger <aj at suse dot de>
- Cc: binutils at sources dot redhat dot com
- Date: Mon, 11 Feb 2002 19:11:02 +0100
- Subject: Re: Problem with string merging and PC relative relocations
- References: <hoy9i0lyj2.fsf@gee.suse.de>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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