bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ld -lgen -ladm causes assert failure in gnu ld 2.12.1 and 2.13 under


From: Jakub Jelinek
Subject: Re: ld -lgen -ladm causes assert failure in gnu ld 2.12.1 and 2.13 under Solaris 2.7 or 2.8
Date: Mon, 23 Sep 2002 15:43:25 +0200
User-agent: Mutt/1.2.5.1i

On Mon, Sep 23, 2002 at 09:34:50AM -0400, Andrew Koenig wrote:
> Jakub> Oh well, Sun changing the rules.
> Jakub> It seems like ld.so behaviour changes based on whether DT_RELACOUNT is
> Jakub> seen or not.
> Jakub> If DT_RELACOUNT is not seen, R_SPARC_RELATIVE relocs are resolved as
> Jakub> *(long *) rela->r_offset += l_addr + rela->r_addend;
> Jakub> while if DT_RELACOUNT is seen, it is resolved as:
> Jakub> *(long *) rela->r_offset = l_addr + rela->r_addend;
> 
> Jakub> Traditionally, Sun ld (for elf32_sparc) created all .rela.got RELATIVE
> Jakub> relocations with r_addend 0 and the addend in memory pointed by it 
> while other
> Jakub> RELATIVE had the addend in r_addend and *r_offset 0.
> 
> Don't know what DT_RELACOUNT is, but I get the idea.

DT_RELACOUNT is a .dynamic tag which allows the dynamic linker optimize
relative relocs - if it is present, it is the number of RELATIVE
relocs at the start of dynamic relocation section (and other types
of relocations must not occur in between).

> Sounds like one implication is that -zcombreloc doesn't work on
> Sparc, period, but that it may not be too hard to fix.

It is trivial to fix, the above was just rant about Sun changing
RELATIVE reloc resolving for the 3rd time (initially it used to be
that r_addend was not taken into account).

> If someone has a patch I can try, I'd be glad to do so.

I'll commit a fix today.

        Jakub




reply via email to

[Prev in Thread] Current Thread [Next in Thread]