Problem with string merging and PC relative relocations
Andreas Jaeger
aj@suse.de
Mon Feb 11 11:49:00 GMT 2002
Jakub Jelinek <jakub@redhat.com> writes:
> 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.
tc-i386.c (x86-64 shared the code with i386) modifies the addend in
tc_gen_reloc. Is that wrong?
How should offset and addend get adjusted for it?
Andreas
--
Andreas Jaeger
SuSE Labs aj@suse.de
private aj@arthur.inka.de
http://www.suse.de/~aj
More information about the Binutils
mailing list