This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Sparc32 ELF TLS fixes


On Mon, 11 Apr 2005 10:20:10 +0930
Alan Modra <amodra@bigpond.net.au> wrote:

> On Sun, Apr 10, 2005 at 05:09:45PM -0700, David S. Miller wrote:
> > code output after linking.  So in the sparc case, for example,
> > the c++ function _ZN3FooC1EPc starts in sr3.o with:
> > 
> > 00000000 <_ZN3FooC1EPc>:
> >    0:	05 00 00 00 	sethi  %hi(0), %g2
> 
> What's the reloc here?

It's a relocation to _ZN3Foo4foosE, of type R_SPARC_HI22.
In sr1 it's at address 0x1120c in the BSS.

sr3.o is used purely to build sr2.sr in this testcase.  So I
guess the elf32-sparc backend should be resolving these relocations
first, then the SREC backend outputs the SREC records?

So the comparison failure looks like this:

comparison failure 3:
S21400100005000044C200A20C82006001C220A20CAF
S21400100005000044C200A21082006001C220A210A7

The first line corresponds to:

S21400100005000044C200A20C82006001C220A20CAF
   0:	05 00 00 44 	sethi  %hi(0x11000), %g2
   4:	c2 00 a2 0c 	ld  [ %g2 + 0x20c ], %g1	! 1120c <foo2+0x11204>
   8:	82 00 60 01 	inc  %g1
   c:	c2 20 a2 0c 	st  %g1, [ %g2 + 0x20c ]

the second line corresponds to:
S21400100005000044C200A21082006001C220A210A7
   8:	05 00 00 44 	sethi  %hi(0x11000), %g2
   c:	c2 00 a2 10 	ld  [ %g2 + 0x210 ], %g1	! 11210 <foo2+0x11208>
  18:	82 00 60 01 	inc  %g1
  1c:	c2 20 a2 10 	st  %g1, [ %g2 + 0x210 ]

So this relocation is being resolved to two different addresses in the two
cases.  In the first it's ending up at 0x1120c and in the second it's
ending up at 0x11210.

So it is being resolved, just to a different spot.
This second case is from running this:

/home/davem/src/BINUTILS/build-sparc32-linux/ld/ld-new  -o tmpdir/sr2.sr --traditional-format -Ttext 0x1000 --oformat srec tmpdir/sr3.o

So as a test I ran this as:

/home/davem/src/BINUTILS/build-sparc32-linux/ld/ld-new  -o sr2.test --traditional-format -Ttext 0x1000 tmpdir/sr3.o

And sr2.test has the symbol at 0x1120c.  So when generating the srec output
format, the symbol ends up at 0x11210 instead of 0x1120c.

I guess I should internally dump the sections, in particular the BSS, while
these two cases are running to figure out why they are being composed
differently?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]