Re: [PATCH] Sparc32 ELF TLS fixes

["David S. Miller" <davem at davemloft dot net>]

On Sun, 10 Apr 2005 14:35:10 -0700
"David S. Miller" <davem@davemloft.net> wrote:

> On Sun, 10 Apr 2005 11:31:30 +0200
> Christian Joensson <christian.joensson@gmail.com> wrote:
> 
> > With your patch applied, I still get
> > http://sourceware.org/bugzilla/show_bug.cgi?id=817: 
> 
> I'll look into it.  I don't see this failure, although
> I'm using gcc-3.4 (you're using gcc-4.x) and I'm using
> a 64-bit build (you're using a 32-bit one).

Ok, I can reproduce this when I build a 32-bit toolchain.

I wouldn't worry about this failure so much, SREC format
is for obscure EEPROM loaders :-)

Anyways, this test is very peculiar.  It's passing or failure
depends upon the contents of the first instructions of C++
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

whereas in sr1 it starts with:

00001000 <_ZN3FooC1EPc>:
    1000:	05 00 00 44 	sethi  %hi(0x11000), %g2

since the symbol reference made in the sethi instruction is resolved.

So the data field in the two SREC files are going to be different, and
therefore of course there will be SREC file output differences.

It seems to pass for the sparc64 native build because these functions
start with stack frame allocation "save" instructions which are not affected
by relocation as the sethi instructions above are.

I can't see how this kind of test case can pass reliably.  In fact I see many
platforms mark this as XFAIL or similar due to relaxation and other issues.

I don't know how this should be resolved.  I bet if you built the tree using
the Solaris SunPRO compiler it might even pass, so marking this xfail for
sparc-*-* might not be reliable either.

Comments?  Anyone?