[PATCH] Fix benign ld testsuite failures on arm-elf

Richard Earnshaw rearnsha@gcc.gnu.org
Mon Aug 8 16:18:00 GMT 2005


On Mon, 2005-08-08 at 17:00, Daniel Jacobowitz wrote:
> On Mon, Aug 08, 2005 at 04:52:58PM +0100, Richard Earnshaw wrote:
> > I've fixed _stack to now be expected in the ABS section.  This seems to
> > be the 'right thing'.  The other changes were simply to offsets in the
> > files for dumps of a shared library.  These addresses have changed
> > because the hash tables have changed as a consequence of this.  It seems
> > that these tests shouldn't really be relying on the dumped code
> > appearing at some specific address, so I've changed the tests to be more
> > general.
> 
> I was trying to test that the relocations were put in the right places
> in the GOT.  It does make the tests a bear to maintain, but it also
> makes them more thorough... I did get this wrong a couple times while
> working on TLS.
> 
> In any case:
> 
> > !  .*:	00008098 	muleq	r0, r8, r0
> > !  .*:	0000808c 	andeq	r8, r0, ip, lsl #1
> 
> If you don't want to rely on the offsets, you'd better change those
> too.  I believe they're pcrel displacements to the GOT entries.

If you want to test that then I'd suggest changing the way we dump the
file so that we use 'objdump -RwDz --section .got'  That gives the
following dump output

tls-lib.so:     file format elf32-littlearm

Disassembly of section .got:

00008390 <.got>:
    8390:       00008320        andeq   r8, r0, r0, lsr #6
    8394:       00000000        andeq   r0, r0, r0
    8398:       00000000        andeq   r0, r0, r0
    839c:       00000000        andeq   r0, r0, r0      839c: R_ARM_TLS_DTPMOD32*ABS*
    83a0:       00000000        andeq   r0, r0, r0
    83a4:       00000000        andeq   r0, r0, r0      83a4: R_ARM_TLS_DTPMOD32lib_gd
    83a8:       00000000        andeq   r0, r0, r0      83a8: R_ARM_TLS_DTPOFF32lib_gd

and we can safely remove the addresses (and the mnemonics, since they
aren't interesting).  We can then use '<.got>' as the main key and we
eliminate the address dependency while still guaranteeing the correct
relative placement.

R.



More information about the Binutils mailing list