Re: Problem with string merging and PC relative relocations

[Andreas Jaeger <aj at suse dot de>]

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