[PATCH] Sparc32 ELF TLS fixes

[PATCH] Sparc32 ELF TLS fixes

[David S. Miller]

While working on Sparc64 ELF TLS support, I found a bug in TLS
handling on sparc32 ELF TLS.

For relocations R_SPARC_TLS_*_{HIX22,LOX10} it clearly states at:

http://docsun.cities.uiuc.edu/sun_docs/C/Solaris_9/SUNWdev/LLM/p60.html

that the formula for R_SPARC_TLS_LDO_HIX22 is:
	@dtpoff(S + A) >> 10
and for R_SPARC_TLS_LDO_LOX10 it is:
	@dtpoff(S + A) & 0x3ff

furthermore it describes for R_SPARC_TLS_LE_HIX22 that the
formula is:
	(@tpoff(S + A) ^ 0xffffffffffffffff) >> 10
and for R_SPARC_TLS_LE_LOX10 it is:
	(@tpoff(S + A) & 0x3ff) | 0x1c00

In the elf32-sparc BFD code we were making two mistakes:

1) we were not transitioning from LDO --> LE properly when
   not shared
2) For the TLS HIX22/LOX10 relocations, we should only do the
   "reloc ^ -1" and "reloc ^ 0x1c00" transformations for the
   LE case

So here are two patches to address these problems.  The first
does the BFD fixes, the next does the LD testsuite update.

I verified these changes with elf32-sparc builds of GLIBC current
CVS, both with NPTL and LINUXTHREADS.  The full ld testsuite passes.

2005-04-09  David S. Miller  <davem@davemloft.net>

	* elf32-sparc.c (elf32_sparc_relocate_section,
	R_SPARC_TLS_LDO_{HIX22,LOX10}): When not shared, transition to
	R_SPARC_TLS_LE_{HIX22,LOX10}.
	(elf32_sparc_relocate_section, R_SPARC_TLS_{LDO,LE}_HIX22): Only
	xor relocation with 0xffffffff if R_SPARC_TLS_LE_HIX22.
	(elf32_sparc_relocate_section, R_SPARC_TLS_{LDO,LE}_LOX10): Only
	or 0x1c00 into relocation if R_SPARC_TLS_LE_HIX22.
	
*** bfd/elf32-sparc.c	11 Jan 2005 09:32:51 -0000	1.79
--- bfd/elf32-sparc.c	10 Apr 2005 05:21:55 -0000
***************
*** 2678,2687 ****
  	case R_SPARC_TLS_LDO_HIX22:
  	case R_SPARC_TLS_LDO_LOX10:
  	  if (info->shared)
! 	    relocation -= dtpoff_base (info);
! 	  else
! 	    relocation = tpoff (info, relocation);
! 	  break;
  
  	case R_SPARC_TLS_LE_HIX22:
  	case R_SPARC_TLS_LE_LOX10:
--- 2678,2691 ----
  	case R_SPARC_TLS_LDO_HIX22:
  	case R_SPARC_TLS_LDO_LOX10:
  	  if (info->shared)
! 	    {
! 	      relocation -= dtpoff_base (info);
! 	      break;
! 	    }
! 
! 	  r_type = (r_type == R_SPARC_TLS_LDO_HIX22
! 		    ? R_SPARC_TLS_LE_HIX22 : R_SPARC_TLS_LE_LOX10);
! 	  /* Fall through.  */
  
  	case R_SPARC_TLS_LE_HIX22:
  	case R_SPARC_TLS_LE_LOX10:
***************
*** 2900,2906 ****
  	  bfd_vma x;
  
  	  relocation += rel->r_addend;
! 	  relocation = relocation ^ 0xffffffff;
  
  	  x = bfd_get_32 (input_bfd, contents + rel->r_offset);
  	  x = (x & ~(bfd_vma) 0x3fffff) | ((relocation >> 10) & 0x3fffff);
--- 2904,2911 ----
  	  bfd_vma x;
  
  	  relocation += rel->r_addend;
! 	  if (r_type == R_SPARC_TLS_LE_HIX22)
! 	    relocation = relocation ^ 0xffffffff;
  
  	  x = bfd_get_32 (input_bfd, contents + rel->r_offset);
  	  x = (x & ~(bfd_vma) 0x3fffff) | ((relocation >> 10) & 0x3fffff);
***************
*** 2913,2919 ****
  	  bfd_vma x;
  
  	  relocation += rel->r_addend;
! 	  relocation = (relocation & 0x3ff) | 0x1c00;
  
  	  x = bfd_get_32 (input_bfd, contents + rel->r_offset);
  	  x = (x & ~(bfd_vma) 0x1fff) | relocation;
--- 2918,2926 ----
  	  bfd_vma x;
  
  	  relocation += rel->r_addend;
! 	  relocation &= 0x3ff;
! 	  if (r_type == R_SPARC_TLS_LE_LOX10)
! 	    relocation |= 0x1c00;
  
  	  x = bfd_get_32 (input_bfd, contents + rel->r_offset);
  	  x = (x & ~(bfd_vma) 0x1fff) | relocation;

2005-04-09  David S. Miller  <davem@davemloft.net>

	* ld-sparc/tlssunbin32.dd: Update for TLS relocation fixes.
	* ld-sparc/tlssunbin32.rd: Likewise.
	* ld-sparc/tlssunbin32.sd: Likewise.

*** ld/testsuite/ld-sparc/tlssunbin32.dd	1 Jul 2004 16:24:51 -0000	1.2
--- ld/testsuite/ld-sparc/tlssunbin32.dd	10 Apr 2005 05:21:57 -0000
***************
*** 16,22 ****
   +11008:	9d e3 bf 98 	save  %sp, -104, %sp
   +1100c:	2f 00 00 48 	sethi  %hi\(0x12000\), %l7
   +11010:	7f ff ff fc 	call  11000 <.*>
!  +11014:	ae 05 e2 68 	add  %l7, 0x268, %l7	! 12268 <.*>
   +11018:	01 00 00 00 	nop *
   +1101c:	01 00 00 00 	nop *
   +11020:	01 00 00 00 	nop *
--- 16,22 ----
   +11008:	9d e3 bf 98 	save  %sp, -104, %sp
   +1100c:	2f 00 00 48 	sethi  %hi\(0x12000\), %l7
   +11010:	7f ff ff fc 	call  11000 <.*>
!  +11014:	ae 05 e2 64 	add  %l7, 0x264, %l7	! 12264 <.*>
   +11018:	01 00 00 00 	nop *
   +1101c:	01 00 00 00 	nop *
   +11020:	01 00 00 00 	nop *
***************
*** 172,178 ****
  00012000 <_start>:
   +12000:	9d e3 bf 98 	save  %sp, -104, %sp
   +12004:	29 00 00 8c 	sethi  %hi\(0x23000\), %l4
!  +12008:	a8 15 22 78 	or  %l4, 0x278, %l4	! 23278 <.*>
   +1200c:	01 00 00 00 	nop *
   +12010:	01 00 00 00 	nop *
   +12014:	01 00 00 00 	nop *
--- 172,178 ----
  00012000 <_start>:
   +12000:	9d e3 bf 98 	save  %sp, -104, %sp
   +12004:	29 00 00 8c 	sethi  %hi\(0x23000\), %l4
!  +12008:	a8 15 22 74 	or  %l4, 0x274, %l4	! 23274 <.*>
   +1200c:	01 00 00 00 	nop *
   +12010:	01 00 00 00 	nop *
   +12014:	01 00 00 00 	nop *
*** ld/testsuite/ld-sparc/tlssunbin32.rd	16 Mar 2005 21:52:47 -0000	1.4
--- ld/testsuite/ld-sparc/tlssunbin32.rd	10 Apr 2005 05:21:57 -0000
***************
*** 17,24 ****
   +\[ 6\] .text +PROGBITS +0+11000 0+1000 0+1194 00 +AX +0 +0 4096
   +\[ 7\] .tdata +PROGBITS +0+22194 0+2194 0+1060 00 WAT +0 +0 +4
   +\[ 8\] .tbss +NOBITS +0+231f4 0+31f4 0+40 00 WAT +0 +0 +4
!  +\[ 9\] .dynamic +DYNAMIC +0+231f8 0+31f8 0+80 08 +WA +4 +0 +4
!  +\[10\] .got +PROGBITS +0+23278 0+3278 0+14 04 +WA +0 +0 +4
   +\[11\] .plt +.*
   +\[12\] .shstrtab +.*
   +\[13\] .symtab +.*
--- 17,24 ----
   +\[ 6\] .text +PROGBITS +0+11000 0+1000 0+1194 00 +AX +0 +0 4096
   +\[ 7\] .tdata +PROGBITS +0+22194 0+2194 0+1060 00 WAT +0 +0 +4
   +\[ 8\] .tbss +NOBITS +0+231f4 0+31f4 0+40 00 WAT +0 +0 +4
!  +\[ 9\] .dynamic +DYNAMIC +0+231f4 0+31f4 0+80 08 +WA +4 +0 +4
!  +\[10\] .got +PROGBITS +0+23274 0+3274 0+14 04 +WA +0 +0 +4
   +\[11\] .plt +.*
   +\[12\] .shstrtab +.*
   +\[13\] .symtab +.*
***************
*** 35,57 ****
   +INTERP +0x0+f4 0x0+100f4 0x0+100f4 0x0+11 0x0+11 R +0x1
  .*Requesting program interpreter.*
   +LOAD +0x0+ 0x0+10000 0x0+10000 0x0+2194 0x0+2194 R E 0x10000
!  +LOAD +0x0+2194 0x0+22194 0x0+22194 0x0+10f8 0x0+10f8 RWE 0x10000
!  +DYNAMIC +0x0+31f8 0x0+231f8 0x0+231f8 0x0+80 0x0+80 RW +0x4
   +TLS +0x0+2194 0x0+22194 0x0+22194 0x0+1060 0x0+10a0 R +0x4
  #...
  
  Relocation section '.rela.dyn' at offset 0x[0-9a-f]+ contains 4 entries:
   Offset +Info +Type +Sym. Value +Symbol's Name \+ Addend
! 0002327c +0000014e R_SPARC_TLS_TPOFF32 +00000000 +sG5 \+ 0
! 00023280 +0000034e R_SPARC_TLS_TPOFF32 +00000000 +sG2 \+ 0
! 00023284 +0000074e R_SPARC_TLS_TPOFF32 +00000000 +sG6 \+ 0
! 00023288 +0000084e R_SPARC_TLS_TPOFF32 +00000000 +sG1 \+ 0
  
  Symbol table '.dynsym' contains 11 entries:
   +Num: +Value +Size Type +Bind +Vis +Ndx Name
   +0: 0+ +0 NOTYPE +LOCAL +DEFAULT +UND *
   +1: 0+ +0 TLS +GLOBAL DEFAULT +UND sG5
!  +2: 0+231f8 +0 OBJECT +GLOBAL DEFAULT +ABS _DYNAMIC
   +3: 0+ +0 TLS +GLOBAL DEFAULT +UND sG2
   +4: [0-9a-f]+ +0 OBJECT +GLOBAL DEFAULT +ABS _PROCEDURE_LINKAGE_TABLE_
   +5: 0+ +0 FUNC +GLOBAL DEFAULT +UND __tls_get_addr
--- 35,57 ----
   +INTERP +0x0+f4 0x0+100f4 0x0+100f4 0x0+11 0x0+11 R +0x1
  .*Requesting program interpreter.*
   +LOAD +0x0+ 0x0+10000 0x0+10000 0x0+2194 0x0+2194 R E 0x10000
!  +LOAD +0x0+2194 0x0+22194 0x0+22194 0x0+10f4 0x0+10f4 RWE 0x10000
!  +DYNAMIC +0x0+31f4 0x0+231f4 0x0+231f4 0x0+80 0x0+80 RW +0x4
   +TLS +0x0+2194 0x0+22194 0x0+22194 0x0+1060 0x0+10a0 R +0x4
  #...
  
  Relocation section '.rela.dyn' at offset 0x[0-9a-f]+ contains 4 entries:
   Offset +Info +Type +Sym. Value +Symbol's Name \+ Addend
! 00023278 +0000014e R_SPARC_TLS_TPOFF32 +00000000 +sG5 \+ 0
! 0002327c +0000034e R_SPARC_TLS_TPOFF32 +00000000 +sG2 \+ 0
! 00023280 +0000074e R_SPARC_TLS_TPOFF32 +00000000 +sG6 \+ 0
! 00023284 +0000084e R_SPARC_TLS_TPOFF32 +00000000 +sG1 \+ 0
  
  Symbol table '.dynsym' contains 11 entries:
   +Num: +Value +Size Type +Bind +Vis +Ndx Name
   +0: 0+ +0 NOTYPE +LOCAL +DEFAULT +UND *
   +1: 0+ +0 TLS +GLOBAL DEFAULT +UND sG5
!  +2: 0+231f4 +0 OBJECT +GLOBAL DEFAULT +ABS _DYNAMIC
   +3: 0+ +0 TLS +GLOBAL DEFAULT +UND sG2
   +4: [0-9a-f]+ +0 OBJECT +GLOBAL DEFAULT +ABS _PROCEDURE_LINKAGE_TABLE_
   +5: 0+ +0 FUNC +GLOBAL DEFAULT +UND __tls_get_addr
***************
*** 99,105 ****
   +[0-9]+: 0+1074 +0 TLS +GLOBAL DEFAULT +8 bg6
   +[0-9]+: 0+ +0 TLS +GLOBAL DEFAULT +UND sG5
   +[0-9]+: 0+1068 +0 TLS +GLOBAL DEFAULT +8 bg3
!  +[0-9]+: 0+231f8 +0 OBJECT +GLOBAL DEFAULT +ABS _DYNAMIC
   +[0-9]+: 0+1008 +0 TLS +GLOBAL DEFAULT +7 sg3
   +[0-9]+: 0+1048 +0 TLS +GLOBAL HIDDEN +7 sh3
   +[0-9]+: 0+ +0 TLS +GLOBAL DEFAULT +UND sG2
--- 99,105 ----
   +[0-9]+: 0+1074 +0 TLS +GLOBAL DEFAULT +8 bg6
   +[0-9]+: 0+ +0 TLS +GLOBAL DEFAULT +UND sG5
   +[0-9]+: 0+1068 +0 TLS +GLOBAL DEFAULT +8 bg3
!  +[0-9]+: 0+231f4 +0 OBJECT +GLOBAL DEFAULT +ABS _DYNAMIC
   +[0-9]+: 0+1008 +0 TLS +GLOBAL DEFAULT +7 sg3
   +[0-9]+: 0+1048 +0 TLS +GLOBAL HIDDEN +7 sh3
   +[0-9]+: 0+ +0 TLS +GLOBAL DEFAULT +UND sG2
***************
*** 124,130 ****
   +[0-9]+: 0+1014 +0 TLS +GLOBAL DEFAULT +7 sg6
   +[0-9]+: 0+1018 +0 TLS +GLOBAL DEFAULT +7 sg7
   +[0-9]+: [0-9a-f]+ +0 NOTYPE +GLOBAL DEFAULT +ABS _edata
!  +[0-9]+: 0+23278 +0 OBJECT +GLOBAL +HIDDEN +10 _GLOBAL_OFFSET_TABLE_
   +[0-9]+: [0-9a-f]+ +0 NOTYPE +GLOBAL DEFAULT +ABS _end
   +[0-9]+: 0+1044 +0 TLS +GLOBAL HIDDEN +7 sh2
   +[0-9]+: 0+1054 +0 TLS +GLOBAL HIDDEN +7 sh6
--- 124,130 ----
   +[0-9]+: 0+1014 +0 TLS +GLOBAL DEFAULT +7 sg6
   +[0-9]+: 0+1018 +0 TLS +GLOBAL DEFAULT +7 sg7
   +[0-9]+: [0-9a-f]+ +0 NOTYPE +GLOBAL DEFAULT +ABS _edata
!  +[0-9]+: 0+23274 +0 OBJECT +GLOBAL +HIDDEN +10 _GLOBAL_OFFSET_TABLE_
   +[0-9]+: [0-9a-f]+ +0 NOTYPE +GLOBAL DEFAULT +ABS _end
   +[0-9]+: 0+1044 +0 TLS +GLOBAL HIDDEN +7 sh2
   +[0-9]+: 0+1054 +0 TLS +GLOBAL HIDDEN +7 sh6
*** ld/testsuite/ld-sparc/tlssunbin32.sd	1 Oct 2004 11:11:28 -0000	1.3
--- ld/testsuite/ld-sparc/tlssunbin32.sd	10 Apr 2005 05:21:57 -0000
***************
*** 7,11 ****
  .*: +file format elf32-sparc
  
  Contents of section .got:
!  23278 000231f8 0+ 0+ 0+  .*
!  23288 0+  .*
--- 7,11 ----
  .*: +file format elf32-sparc
  
  Contents of section .got:
!  23274 000231f4 0+ 0+ 0+  .*
!  23284 0+  .*

Re: [PATCH] Sparc32 ELF TLS fixes

[Christian Joensson]

On Apr 10, 2005 7:46 AM, David S. Miller <davem@davemloft.net> wrote:
> 
> While working on Sparc64 ELF TLS support, I found a bug in TLS
> handling on sparc32 ELF TLS.

With your patch applied, I still get
http://sourceware.org/bugzilla/show_bug.cgi?id=817: 

g++ -m32 -L/usr/local/src/trunk/objdir-binutils32/./ld -g -O2
-fno-exceptions
-B/usr/local/src/trunk/objdir-binutils32/ld/tmpdir/gas/
-I/usr/local/src/trunk/src/ld/testsuite/ld-srec -g -O2  -c
/usr/local/src/trunk/src/ld/testsuite/ld-srec/sr3.cc -o tmpdir/sr3.o
/usr/local/src/trunk/objdir-binutils32/ld/ld-new  -o tmpdir/sr1
--traditional-format -Ttext 0x1000 tmpdir/sr3.o
/usr/local/src/trunk/objdir-binutils32/ld/ld-new  -o tmpdir/sr2.sr
--traditional-format -Ttext 0x1000 --oformat srec tmpdir/sr3.o
/usr/local/src/trunk/objdir-binutils32/ld/../binutils/objcopy -O srec
tmpdir/sr1 tmpdir/sr1.sr
comparison failure 3:
S21400100005000044C200A20C82006001C220A20CAF
S21400100005000044C200A21082006001C220A210A7
FAIL: S-records with constructors

but the TLS FAIL I had is gone,
see http://sourceware.org/bugzilla/show_bug.cgi?id=816
but replaced by a new one:

Running /usr/local/src/trunk/src/ld/testsuite/ld-sparc/sparc.exp ...
/usr/local/src/trunk/objdir-binutils32/ld/../gas/as-new   -o
tmpdir/tlssunpic32.o --32 -K PIC
/usr/local/src/trunk/src/ld/testsuite/ld-sparc/tlssunpic32.s
/usr/local/src/trunk/objdir-binutils32/ld/../gas/as-new   -o
tmpdir/tlspic.o --32 -K PIC
/usr/local/src/trunk/src/ld/testsuite/ld-sparc/tlspic.s
/usr/local/src/trunk/objdir-binutils32/ld/ld-new  -o
tmpdir/libtlssunpic32.so
-L/usr/local/src/trunk/src/ld/testsuite/ld-sparc -shared -melf32_sparc
tmpdir/tlssunpic32.o tmpdir/tlspic.o
/usr/local/src/trunk/objdir-binutils32/ld/../binutils/readelf -WSsrl
tmpdir/libtlssunpic32.so > dump.out
/usr/local/src/trunk/objdir-binutils32/ld/../binutils/objdump
-drj.text tmpdir/libtlssunpic32.so > dump.out
regexp_diff match failure
regexp "^ +1174:	27 3f ff ff 	sethi  %hi\(0xfffffc00\), %l3$"
line   "    1174:	27 00 00 00 	sethi  %hi(0), %l3"
regexp_diff match failure
regexp "^ +117c:	a8 1c fc 20 	xor  %l3, -992, %l4$"
line   "    117c:	a8 1c e0 20 	xor  %l3, 0x20, %l4"
regexp_diff match failure
regexp "^ +118c:	25 3f ff ff 	sethi  %hi\(0xfffffc00\), %l2$"
line   "    118c:	25 00 00 00 	sethi  %hi(0), %l2"
regexp_diff match failure
regexp "^ +1194:	a6 1c bc 26 	xor  %l2, -986, %l3$"
line   "    1194:	a6 1c a0 26 	xor  %l2, 0x26, %l3"
regexp_diff match failure
regexp "^ +11b4:	27 3f ff ff 	sethi  %hi\(0xfffffc00\), %l3$"
line   "    11b4:	27 00 00 00 	sethi  %hi(0), %l3"
regexp_diff match failure
regexp "^ +11bc:	25 3f ff ff 	sethi  %hi\(0xfffffc00\), %l2$"
line   "    11bc:	25 00 00 00 	sethi  %hi(0), %l2"
regexp_diff match failure
regexp "^ +11c4:	a8 1c fc 40 	xor  %l3, -960, %l4$"
line   "    11c4:	a8 1c e0 40 	xor  %l3, 0x40, %l4"
regexp_diff match failure
regexp "^ +11cc:	a6 1c bc 45 	xor  %l2, -955, %l3$"
line   "    11cc:	a6 1c a0 45 	xor  %l2, 0x45, %l3"
regexp_diff match failure
regexp "^ +11ec:	27 3f ff ff 	sethi  %hi\(0xfffffc00\), %l3$"
line   "    11ec:	27 00 00 00 	sethi  %hi(0), %l3"
regexp_diff match failure
regexp "^ +11f4:	25 3f ff ff 	sethi  %hi\(0xfffffc00\), %l2$"
line   "    11f4:	25 00 00 00 	sethi  %hi(0), %l2"
regexp_diff match failure
regexp "^ +11fc:	a8 1c fc 63 	xor  %l3, -925, %l4$"
line   "    11fc:	a8 1c e0 63 	xor  %l3, 0x63, %l4"
regexp_diff match failure
regexp "^ +1204:	a6 1c bc 64 	xor  %l2, -924, %l3$"
line   "    1204:	a6 1c a0 64 	xor  %l2, 0x64, %l3"
FAIL: TLS -fpic -shared transitions

---
Cheers,

/ChJ

Re: [PATCH] Sparc32 ELF TLS fixes

[David S. Miller]

On Sun, 10 Apr 2005 11:31:30 +0200
Christian Joensson <christian.joensson@gmail.com> wrote:

> but the TLS FAIL I had is gone,
> see http://sourceware.org/bugzilla/show_bug.cgi?id=816
> but replaced by a new one:

Did you apply the testsuite patch I attached as well?
It specifically fixes up the regex mis-matches you posted.

Re: [PATCH] Sparc32 ELF TLS fixes

[David S. Miller]

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).

Re: [PATCH] Sparc32 ELF TLS fixes

[David S. Miller]

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?

Re: [PATCH] Sparc32 ELF TLS fixes

[Alan Modra]

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?

> 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.

Well, it should be resolved when linking to srec output too.  The
problem is likely that the srec linker doesn't handle the reloc
properly.  ie. The reloc special_function is buggy or missing.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: [PATCH] Sparc32 ELF TLS fixes

[David S. Miller]

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?

Re: [PATCH] Sparc32 ELF TLS fixes

[Alan Modra]

On Sun, Apr 10, 2005 at 06:15:48PM -0700, David S. Miller wrote:
> 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?

It might simply be that the two bss sections start at different
addresses.  Perhaps they have different alignments for some reason.
Perhaps a different start address is caused by pruning of unused
sections in the ELF linker but not the SREC one.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: [PATCH] Sparc32 ELF TLS fixes

[David S. Miller]

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

> It might simply be that the two bss sections start at different
> addresses.  Perhaps they have different alignments for some reason.
> Perhaps a different start address is caused by pruning of unused
> sections in the ELF linker but not the SREC one.

That's a good guess.  The elf32-sparc BFD backend does garbage
collection.

I'll look more deeply into this.

Re: [PATCH] Sparc32 ELF TLS fixes

[David S. Miller]

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

> On Mon, 11 Apr 2005 11:19:26 +0930
> Alan Modra <amodra@bigpond.net.au> wrote:
> 
> > It might simply be that the two bss sections start at different
> > addresses.  Perhaps they have different alignments for some reason.
> > Perhaps a different start address is caused by pruning of unused
> > sections in the ELF linker but not the SREC one.
> 
> That's a good guess.  The elf32-sparc BFD backend does garbage
> collection.
> 
> I'll look more deeply into this.

The sizing of the .rodata section changes.  When outputting elf it
gets a size of 0x1b, but when outputting SREC it gets sized to
32.

Regardless of the cause for this .rodata size different, the net
effect is that the .bss will be at a different offset and thus the
relocations we talked about yesterday will change.

This change in output .rodata size is because, at size_input_section()
time, the input .rodata section is seen as having a different size.
In the ELF output case it is 27, in the SREC output case it is 32.

[ ... more fuddling around in gdb ... ]

The .rodata starts as .rodata.str1.8 in sr3.o:

Contents of section .rodata.str1.8:
 0000 6175746f 6d617469 635f666f 6f000000  automatic_foo...
 0010 73746174 69635f66 6f6f0000 00000000  static_foo......

It is in fact 32 bytes.  But something causes it to shrink when
outputting ELF.  And this something is _bfd_elf_merge_sections().
The above is the only .rodata.* section, so it is the only one
processed during _bfd_merge_sections().  It trims the strings so
that there are no spurious NULL bytes.  And that's how we end up
with a 27 byte .rodata output section from the original 32 byte
input section.

I don't see any reasonable way to fix this besides possibly disabling
section merging via command line option for this test case.  Is there
even a way to turn SEC_MERGE processing off from the ld command line?

Alan?

Re: [PATCH] Sparc32 ELF TLS fixes

[Jakub Jelinek]

On Sat, Apr 09, 2005 at 10:46:45PM -0700, David S. Miller wrote:
> While working on Sparc64 ELF TLS support, I found a bug in TLS
> handling on sparc32 ELF TLS.
> 
> For relocations R_SPARC_TLS_*_{HIX22,LOX10} it clearly states at:
> 
> http://docsun.cities.uiuc.edu/sun_docs/C/Solaris_9/SUNWdev/LLM/p60.html
> 
> that the formula for R_SPARC_TLS_LDO_HIX22 is:
> 	@dtpoff(S + A) >> 10
> and for R_SPARC_TLS_LDO_LOX10 it is:
> 	@dtpoff(S + A) & 0x3ff

The relocation are then misnamed, but guess we have to live with that.
The values used in those relocations are never negative, so it makes sense.

> 2005-04-09  David S. Miller  <davem@davemloft.net>
> 
> 	* elf32-sparc.c (elf32_sparc_relocate_section,
> 	R_SPARC_TLS_LDO_{HIX22,LOX10}): When not shared, transition to
> 	R_SPARC_TLS_LE_{HIX22,LOX10}.
> 	(elf32_sparc_relocate_section, R_SPARC_TLS_{LDO,LE}_HIX22): Only
> 	xor relocation with 0xffffffff if R_SPARC_TLS_LE_HIX22.
> 	(elf32_sparc_relocate_section, R_SPARC_TLS_{LDO,LE}_LOX10): Only
> 	or 0x1c00 into relocation if R_SPARC_TLS_LE_HIX22.

Thanks, please commit.
I see
FAIL: S-records with constructors
failure both without and with this patch (SREC tests don't use TLS,
so that's not surprising).

> 2005-04-09  David S. Miller  <davem@davemloft.net>
> 
> 	* ld-sparc/tlssunbin32.dd: Update for TLS relocation fixes.
> 	* ld-sparc/tlssunbin32.rd: Likewise.
> 	* ld-sparc/tlssunbin32.sd: Likewise.

You apparently missed also:

	* ld-sparc/tlssunpic32.dd: Update for TLS relocation fixes.

--- ld/testsuite/ld-sparc/tlssunpic32.dd.jj	2004-07-01 12:24:18.000000000 -0400
+++ ld/testsuite/ld-sparc/tlssunpic32.dd	2005-04-11 16:00:07.470083241 -0400
@@ -105,15 +105,15 @@ Disassembly of section .text:
  +1168:	01 00 00 00 	nop *
  +116c:	40 00 44 02 	call  [0-9a-f]+ <__tls_get_addr@plt>
  +1170:	01 00 00 00 	nop *
- +1174:	27 3f ff ff 	sethi  %hi\(0xfffffc00\), %l3
+ +1174:	27 00 00 00 	sethi  %hi\(0\), %l3
  +1178:	01 00 00 00 	nop *
- +117c:	a8 1c fc 20 	xor  %l3, -992, %l4
+ +117c:	a8 1c e0 20 	xor  %l3, 0x20, %l4
  +1180:	01 00 00 00 	nop *
  +1184:	aa 02 00 14 	add  %o0, %l4, %l5
  +1188:	01 00 00 00 	nop *
- +118c:	25 3f ff ff 	sethi  %hi\(0xfffffc00\), %l2
+ +118c:	25 00 00 00 	sethi  %hi\(0\), %l2
  +1190:	01 00 00 00 	nop *
- +1194:	a6 1c bc 26 	xor  %l2, -986, %l3
+ +1194:	a6 1c a0 26 	xor  %l2, 0x26, %l3
  +1198:	01 00 00 00 	nop *
  +119c:	ec 12 00 13 	lduh  \[ %o0 \+ %l3 \], %l6
  +11a0:	01 00 00 00 	nop *
@@ -121,13 +121,13 @@ Disassembly of section .text:
  +11a8:	01 00 00 00 	nop *
  +11ac:	01 00 00 00 	nop *
  +11b0:	13 00 00 00 	sethi  %hi\(0\), %o1
- +11b4:	27 3f ff ff 	sethi  %hi\(0xfffffc00\), %l3
+ +11b4:	27 00 00 00 	sethi  %hi\(0\), %l3
  +11b8:	94 02 60 14 	add  %o1, 0x14, %o2
- +11bc:	25 3f ff ff 	sethi  %hi\(0xfffffc00\), %l2
+ +11bc:	25 00 00 00 	sethi  %hi\(0\), %l2
  +11c0:	90 05 c0 0a 	add  %l7, %o2, %o0
- +11c4:	a8 1c fc 40 	xor  %l3, -960, %l4
+ +11c4:	a8 1c e0 40 	xor  %l3, 0x40, %l4
  +11c8:	40 00 43 eb 	call  [0-9a-f]+ <__tls_get_addr@plt>
- +11cc:	a6 1c bc 45 	xor  %l2, -955, %l3
+ +11cc:	a6 1c a0 45 	xor  %l2, 0x45, %l3
  +11d0:	aa 02 00 14 	add  %o0, %l4, %l5
  +11d4:	ec 0a 00 13 	ldub  \[ %o0 \+ %l3 \], %l6
  +11d8:	01 00 00 00 	nop *
@@ -135,13 +135,13 @@ Disassembly of section .text:
  +11e0:	01 00 00 00 	nop *
  +11e4:	01 00 00 00 	nop *
  +11e8:	13 00 00 00 	sethi  %hi\(0\), %o1
- +11ec:	27 3f ff ff 	sethi  %hi\(0xfffffc00\), %l3
+ +11ec:	27 00 00 00 	sethi  %hi\(0\), %l3
  +11f0:	94 02 60 14 	add  %o1, 0x14, %o2
- +11f4:	25 3f ff ff 	sethi  %hi\(0xfffffc00\), %l2
+ +11f4:	25 00 00 00 	sethi  %hi\(0\), %l2
  +11f8:	90 05 c0 0a 	add  %l7, %o2, %o0
- +11fc:	a8 1c fc 63 	xor  %l3, -925, %l4
+ +11fc:	a8 1c e0 63 	xor  %l3, 0x63, %l4
  +1200:	40 00 43 dd 	call  [0-9a-f]+ <__tls_get_addr@plt>
- +1204:	a6 1c bc 64 	xor  %l2, -924, %l3
+ +1204:	a6 1c a0 64 	xor  %l2, 0x64, %l3
  +1208:	aa 02 00 14 	add  %o0, %l4, %l5
  +120c:	ec 02 00 13 	ld  \[ %o0 \+ %l3 \], %l6
  +1210:	01 00 00 00 	nop *


	Jakub

Re: [PATCH] Sparc32 ELF TLS fixes

[Christian Joensson]

On Apr 11, 2005 10:16 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Sat, Apr 09, 2005 at 10:46:45PM -0700, David S. Miller wrote:
> > While working on Sparc64 ELF TLS support, I found a bug in TLS
> > handling on sparc32 ELF TLS.
> >
> > For relocations R_SPARC_TLS_*_{HIX22,LOX10} it clearly states at:
> >
> > http://docsun.cities.uiuc.edu/sun_docs/C/Solaris_9/SUNWdev/LLM/p60.html
> >
> > that the formula for R_SPARC_TLS_LDO_HIX22 is:
> >       @dtpoff(S + A) >> 10
> > and for R_SPARC_TLS_LDO_LOX10 it is:
> >       @dtpoff(S + A) & 0x3ff
> 
> The relocation are then misnamed, but guess we have to live with that.
> The values used in those relocations are never negative, so it makes sense.
> 
> > 2005-04-09  David S. Miller  <davem@davemloft.net>
> >
> >       * elf32-sparc.c (elf32_sparc_relocate_section,
> >       R_SPARC_TLS_LDO_{HIX22,LOX10}): When not shared, transition to
> >       R_SPARC_TLS_LE_{HIX22,LOX10}.
> >       (elf32_sparc_relocate_section, R_SPARC_TLS_{LDO,LE}_HIX22): Only
> >       xor relocation with 0xffffffff if R_SPARC_TLS_LE_HIX22.
> >       (elf32_sparc_relocate_section, R_SPARC_TLS_{LDO,LE}_LOX10): Only
> >       or 0x1c00 into relocation if R_SPARC_TLS_LE_HIX22.
> 
> Thanks, please commit.
> I see
> FAIL: S-records with constructors
> failure both without and with this patch (SREC tests don't use TLS,
> so that's not surprising).
> 
> > 2005-04-09  David S. Miller  <davem@davemloft.net>
> >
> >       * ld-sparc/tlssunbin32.dd: Update for TLS relocation fixes.
> >       * ld-sparc/tlssunbin32.rd: Likewise.
> >       * ld-sparc/tlssunbin32.sd: Likewise.
> 
> You apparently missed also:
> 
>        * ld-sparc/tlssunpic32.dd: Update for TLS relocation fixes.
> 
> --- ld/testsuite/ld-sparc/tlssunpic32.dd.jj     2004-07-01 12:24:18.000000000 -0400
> +++ ld/testsuite/ld-sparc/tlssunpic32.dd        2005-04-11 16:00:07.470083241 -0400
> @@ -105,15 +105,15 @@ Disassembly of section .text:
>  +1168:        01 00 00 00     nop *
>  +116c:        40 00 44 02     call  [0-9a-f]+ <__tls_get_addr@plt>
>  +1170:        01 00 00 00     nop *
> - +1174:        27 3f ff ff     sethi  %hi\(0xfffffc00\), %l3
> + +1174:        27 00 00 00     sethi  %hi\(0\), %l3
>  +1178:        01 00 00 00     nop *
> - +117c:        a8 1c fc 20     xor  %l3, -992, %l4
> + +117c:        a8 1c e0 20     xor  %l3, 0x20, %l4
>  +1180:        01 00 00 00     nop *
>  +1184:        aa 02 00 14     add  %o0, %l4, %l5
>  +1188:        01 00 00 00     nop *
> - +118c:        25 3f ff ff     sethi  %hi\(0xfffffc00\), %l2
> + +118c:        25 00 00 00     sethi  %hi\(0\), %l2
>  +1190:        01 00 00 00     nop *
> - +1194:        a6 1c bc 26     xor  %l2, -986, %l3
> + +1194:        a6 1c a0 26     xor  %l2, 0x26, %l3
>  +1198:        01 00 00 00     nop *
>  +119c:        ec 12 00 13     lduh  \[ %o0 \+ %l3 \], %l6
>  +11a0:        01 00 00 00     nop *
> @@ -121,13 +121,13 @@ Disassembly of section .text:
>  +11a8:        01 00 00 00     nop *
>  +11ac:        01 00 00 00     nop *
>  +11b0:        13 00 00 00     sethi  %hi\(0\), %o1
> - +11b4:        27 3f ff ff     sethi  %hi\(0xfffffc00\), %l3
> + +11b4:        27 00 00 00     sethi  %hi\(0\), %l3
>  +11b8:        94 02 60 14     add  %o1, 0x14, %o2
> - +11bc:        25 3f ff ff     sethi  %hi\(0xfffffc00\), %l2
> + +11bc:        25 00 00 00     sethi  %hi\(0\), %l2
>  +11c0:        90 05 c0 0a     add  %l7, %o2, %o0
> - +11c4:        a8 1c fc 40     xor  %l3, -960, %l4
> + +11c4:        a8 1c e0 40     xor  %l3, 0x40, %l4
>  +11c8:        40 00 43 eb     call  [0-9a-f]+ <__tls_get_addr@plt>
> - +11cc:        a6 1c bc 45     xor  %l2, -955, %l3
> + +11cc:        a6 1c a0 45     xor  %l2, 0x45, %l3
>  +11d0:        aa 02 00 14     add  %o0, %l4, %l5
>  +11d4:        ec 0a 00 13     ldub  \[ %o0 \+ %l3 \], %l6
>  +11d8:        01 00 00 00     nop *
> @@ -135,13 +135,13 @@ Disassembly of section .text:
>  +11e0:        01 00 00 00     nop *
>  +11e4:        01 00 00 00     nop *
>  +11e8:        13 00 00 00     sethi  %hi\(0\), %o1
> - +11ec:        27 3f ff ff     sethi  %hi\(0xfffffc00\), %l3
> + +11ec:        27 00 00 00     sethi  %hi\(0\), %l3
>  +11f0:        94 02 60 14     add  %o1, 0x14, %o2
> - +11f4:        25 3f ff ff     sethi  %hi\(0xfffffc00\), %l2
> + +11f4:        25 00 00 00     sethi  %hi\(0\), %l2
>  +11f8:        90 05 c0 0a     add  %l7, %o2, %o0
> - +11fc:        a8 1c fc 63     xor  %l3, -925, %l4
> + +11fc:        a8 1c e0 63     xor  %l3, 0x63, %l4
>  +1200:        40 00 43 dd     call  [0-9a-f]+ <__tls_get_addr@plt>
> - +1204:        a6 1c bc 64     xor  %l2, -924, %l3
> + +1204:        a6 1c a0 64     xor  %l2, 0x64, %l3
>  +1208:        aa 02 00 14     add  %o0, %l4, %l5
>  +120c:        ec 02 00 13     ld  \[ %o0 \+ %l3 \], %l6
>  +1210:        01 00 00 00     nop *
> 
> 
>        Jakub
> 

I don't seem to be able to apply Jakub's patch... is that supposed to
come after David's, or on a clean file? If I try both... I just get

patching file ld/testsuite/ld-sparc/tlssunpic32.dd
Hunk #1 FAILED at 105.
Hunk #2 FAILED at 121.
Hunk #3 FAILED at 135.
3 out of 3 hunks FAILED -- saving rejects to file
ld/testsuite/ld-sparc/tlssunpic32.dd.rej


-- 
Cheers,

/ChJ

Re: [PATCH] Sparc32 ELF TLS fixes

[David S. Miller]

On Mon, 11 Apr 2005 22:16:06 +0200
Jakub Jelinek <jakub@redhat.com> wrote:

> The relocation are then misnamed, but guess we have to live with that.
> The values used in those relocations are never negative, so it makes sense.

I don't think they are misnamed, the "X" stands for Xor as in "Xor
instruction" or "relocation to a sethi/xor".  Anyways, it's silly
to argue about this :-)

The compiler has to emit XOR instructions in both cases, since we
don't know what the final (post TLS transition) relocation type will
be.

> I see
> FAIL: S-records with constructors
> failure both without and with this patch (SREC tests don't use TLS,
> so that's not surprising).

Yes, this is being discussed in a seperate thread.  When outputting
ELF we get .rodata section merging, when outputting SREC we do not.
So the VMA of the .bss section (which sits after .rodata) changes,
and thus relocations to .bss sections change, and thus instructions
quoted by the SREC records look different, causing the comparison
failure.

There are several tests in the testsuite which potentially suffer from
this kind of problem.  Tests which depend upon strict addresses of
some section will always fail when some new BFD backend optimization or
transformation is added.

> You apparently missed also:
> 
> 	* ld-sparc/tlssunpic32.dd: Update for TLS relocation fixes.

Sorry, I left this out of my patch by accident.

Re: [PATCH] Sparc32 ELF TLS fixes

[David S. Miller]

On Mon, 11 Apr 2005 22:21:19 +0200
Christian Joensson <christian.joensson@gmail.com> wrote:

> On Apr 11, 2005 10:16 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> > You apparently missed also:
> > 
> >        * ld-sparc/tlssunpic32.dd: Update for TLS relocation fixes.
 ...
> I don't seem to be able to apply Jakub's patch... is that supposed to
> come after David's, or on a clean file? If I try both... I just get

Perhaps Jakub's patch is mangled in some way.  Does this one apply
better?

--- ld/testsuite/ld-sparc/tlssunpic32.dd	1 Jul 2004 16:24:51 -0000	1.2
+++ ld/testsuite/ld-sparc/tlssunpic32.dd	11 Apr 2005 20:23:46 -0000
@@ -105,15 +105,15 @@ Disassembly of section .text:
  +1168:	01 00 00 00 	nop *
  +116c:	40 00 44 02 	call  [0-9a-f]+ <__tls_get_addr@plt>
  +1170:	01 00 00 00 	nop *
- +1174:	27 3f ff ff 	sethi  %hi\(0xfffffc00\), %l3
+ +1174:	27 00 00 00 	sethi  %hi\(0\), %l3
  +1178:	01 00 00 00 	nop *
- +117c:	a8 1c fc 20 	xor  %l3, -992, %l4
+ +117c:	a8 1c e0 20 	xor  %l3, 0x20, %l4
  +1180:	01 00 00 00 	nop *
  +1184:	aa 02 00 14 	add  %o0, %l4, %l5
  +1188:	01 00 00 00 	nop *
- +118c:	25 3f ff ff 	sethi  %hi\(0xfffffc00\), %l2
+ +118c:	25 00 00 00 	sethi  %hi\(0\), %l2
  +1190:	01 00 00 00 	nop *
- +1194:	a6 1c bc 26 	xor  %l2, -986, %l3
+ +1194:	a6 1c a0 26 	xor  %l2, 0x26, %l3
  +1198:	01 00 00 00 	nop *
  +119c:	ec 12 00 13 	lduh  \[ %o0 \+ %l3 \], %l6
  +11a0:	01 00 00 00 	nop *
@@ -121,13 +121,13 @@ Disassembly of section .text:
  +11a8:	01 00 00 00 	nop *
  +11ac:	01 00 00 00 	nop *
  +11b0:	13 00 00 00 	sethi  %hi\(0\), %o1
- +11b4:	27 3f ff ff 	sethi  %hi\(0xfffffc00\), %l3
+ +11b4:	27 00 00 00 	sethi  %hi\(0\), %l3
  +11b8:	94 02 60 14 	add  %o1, 0x14, %o2
- +11bc:	25 3f ff ff 	sethi  %hi\(0xfffffc00\), %l2
+ +11bc:	25 00 00 00 	sethi  %hi\(0\), %l2
  +11c0:	90 05 c0 0a 	add  %l7, %o2, %o0
- +11c4:	a8 1c fc 40 	xor  %l3, -960, %l4
+ +11c4:	a8 1c e0 40 	xor  %l3, 0x40, %l4
  +11c8:	40 00 43 eb 	call  [0-9a-f]+ <__tls_get_addr@plt>
- +11cc:	a6 1c bc 45 	xor  %l2, -955, %l3
+ +11cc:	a6 1c a0 45 	xor  %l2, 0x45, %l3
  +11d0:	aa 02 00 14 	add  %o0, %l4, %l5
  +11d4:	ec 0a 00 13 	ldub  \[ %o0 \+ %l3 \], %l6
  +11d8:	01 00 00 00 	nop *
@@ -135,13 +135,13 @@ Disassembly of section .text:
  +11e0:	01 00 00 00 	nop *
  +11e4:	01 00 00 00 	nop *
  +11e8:	13 00 00 00 	sethi  %hi\(0\), %o1
- +11ec:	27 3f ff ff 	sethi  %hi\(0xfffffc00\), %l3
+ +11ec:	27 00 00 00 	sethi  %hi\(0\), %l3
  +11f0:	94 02 60 14 	add  %o1, 0x14, %o2
- +11f4:	25 3f ff ff 	sethi  %hi\(0xfffffc00\), %l2
+ +11f4:	25 00 00 00 	sethi  %hi\(0\), %l2
  +11f8:	90 05 c0 0a 	add  %l7, %o2, %o0
- +11fc:	a8 1c fc 63 	xor  %l3, -925, %l4
+ +11fc:	a8 1c e0 63 	xor  %l3, 0x63, %l4
  +1200:	40 00 43 dd 	call  [0-9a-f]+ <__tls_get_addr@plt>
- +1204:	a6 1c bc 64 	xor  %l2, -924, %l3
+ +1204:	a6 1c a0 64 	xor  %l2, 0x64, %l3
  +1208:	aa 02 00 14 	add  %o0, %l4, %l5
  +120c:	ec 02 00 13 	ld  \[ %o0 \+ %l3 \], %l6
  +1210:	01 00 00 00 	nop *

Re: [PATCH] Sparc32 ELF TLS fixes

[Alan Modra]

On Mon, Apr 11, 2005 at 12:11:33PM -0700, David S. Miller wrote:
> The .rodata starts as .rodata.str1.8 in sr3.o:
> 
> Contents of section .rodata.str1.8:
>  0000 6175746f 6d617469 635f666f 6f000000  automatic_foo...
>  0010 73746174 69635f66 6f6f0000 00000000  static_foo......
> 
> It is in fact 32 bytes.  But something causes it to shrink when
> outputting ELF.  And this something is _bfd_elf_merge_sections().
> The above is the only .rodata.* section, so it is the only one
> processed during _bfd_merge_sections().  It trims the strings so
> that there are no spurious NULL bytes.  And that's how we end up
> with a 27 byte .rodata output section from the original 32 byte
> input section.

That sounds like a ld bug.  The strings shouldn't have their
alignment changed.  Since gcc is emitting them to a .rodata.str1.8
section, I'd expect readelf -S sr3.o should show something like

.. .rodata.str1.8 PROGBITS .. .. .. 01 AMS 0 0 8

The section alignment tells the merge code to not reduce string
alignment below that value.

> I don't see any reasonable way to fix this besides possibly disabling
> section merging via command line option for this test case.  Is there
> even a way to turn SEC_MERGE processing off from the ld command line?

No, this optimization is controlled by the section flags.  Turn it off
with gcc's --fno-merge-constants.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: [PATCH] Sparc32 ELF TLS fixes

[David S. Miller]

On Tue, 12 Apr 2005 08:33:53 +0930
Alan Modra <amodra@bigpond.net.au> wrote:

> That sounds like a ld bug.  The strings shouldn't have their
> alignment changed.  Since gcc is emitting them to a .rodata.str1.8
> section, I'd expect readelf -S sr3.o should show something like
> 
> .. .rodata.str1.8 PROGBITS .. .. .. 01 AMS 0 0 8
> 
> The section alignment tells the merge code to not reduce string
> alignment below that value.

Right, and sorry for not getting back sooner about this.  It does
appear to be a bug in section size assignment in merge_sections().

The section is marked with the correct alignment, and the code
in bfd/merge.c:record_section() is using the correct 8 byte alignment
information (align = 3 and mask = 7).

merge_strings() does not compute the section size correctly in
this loop:

  /* Now assign positions to the strings we want to keep.  */
  size = 0;
  secinfo = sinfo->htab->first->secinfo;
  for (e = sinfo->htab->first; e; e = e->next)
    {
      if (e->secinfo != secinfo)
	{
	  secinfo->sec->size = size;
	  secinfo = e->secinfo;
	}
      if (e->alignment)
	{
	  if (e->secinfo->first_str == NULL)
	    {
	      e->secinfo->first_str = e;
	      size = 0;
	    }
	  size = (size + e->alignment - 1) & ~((bfd_vma) e->alignment - 1);
	  e->u.index = size;
	  size += e->len;
	}
    }
  secinfo->sec->size = size;

For the test case we end up with size at 27 which is not aligned to
a multiple of 8 of course.

Alan, this problem seems to have been introduced by your _raw_size changes
(revision 1.20 --> 1.21 of bfd/merge.c on June 24, 2004).  That line at the
end of the loop quoted above which sets "secinfo->sec->size = size;" came
from those changes.

Re: [PATCH] Sparc32 ELF TLS fixes

[Alan Modra]

On Wed, Apr 13, 2005 at 12:13:40PM -0700, David S. Miller wrote:
> For the test case we end up with size at 27 which is not aligned to
> a multiple of 8 of course.

Hmm, we do usually round up section size according to alignment in the
assembler, so this does qualify as a minor bug.  I call it minor because
padding at the end of a section won't affect anything except placement
of following sections.  The placement isn't wrong for your testcase,
just different from that when using the srec linker.

> Alan, this problem seems to have been introduced by your _raw_size changes
> (revision 1.20 --> 1.21 of bfd/merge.c on June 24, 2004).  That line at the
> end of the loop quoted above which sets "secinfo->sec->size = size;" came
> from those changes.

I don't think this patch changed section sizing for this testcase.
However, since you're dragging me into this I may as well fix it.  :)

	* merge.c (merge_strings): Round up section size for alignment.

Um, after applying this I'm wondering whether we need to bfd_bwrite the
zero bytes?  I know lseek should put zeros in gaps, but I have a nagging
feeling that not all operating systems we support do this.  Anyone?

Index: bfd/merge.c
===================================================================
RCS file: /cvs/src/src/bfd/merge.c,v
retrieving revision 1.22
diff -u -p -r1.22 merge.c
--- bfd/merge.c	20 Feb 2005 14:59:07 -0000	1.22
+++ bfd/merge.c	13 Apr 2005 23:56:41 -0000
@@ -656,6 +656,11 @@ alloc_failure:
 	}
     }
   secinfo->sec->size = size;
+  if (secinfo->sec->alignment_power != 0)
+    {
+      bfd_size_type align = (bfd_size_type) 1 << secinfo->sec->alignment_power;
+      secinfo->sec->size = (secinfo->sec->size + align - 1) & -align;
+    }
 
   /* And now adjust the rest, removing them from the chain (but not hashtable)
      at the same time.  */

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: [PATCH] Sparc32 ELF TLS fixes

[David S. Miller]

On Thu, 14 Apr 2005 10:01:24 +0930
Alan Modra <amodra@bigpond.net.au> wrote:

> However, since you're dragging me into this I may as well fix it.  :)
> 
> 	* merge.c (merge_strings): Round up section size for alignment.

Heh, thanks :-)

I just verified that it does fix the testcase on 32-bit Sparc.

Re: [PATCH] Sparc32 ELF TLS fixes

[Richard Henderson]

On Thu, Apr 14, 2005 at 10:01:24AM +0930, Alan Modra wrote:
> Um, after applying this I'm wondering whether we need to bfd_bwrite the
> zero bytes?  I know lseek should put zeros in gaps, but I have a nagging
> feeling that not all operating systems we support do this.  Anyone?

Windows.


r~

Re: [PATCH] Sparc32 ELF TLS fixes

[Alan Modra]

On Wed, Apr 13, 2005 at 06:27:48PM -0700, Richard Henderson wrote:
> On Thu, Apr 14, 2005 at 10:01:24AM +0930, Alan Modra wrote:
> > Um, after applying this I'm wondering whether we need to bfd_bwrite the
> > zero bytes?  I know lseek should put zeros in gaps, but I have a nagging
> > feeling that not all operating systems we support do this.  Anyone?
> 
> Windows.

Blech.  BeOS too, according to some old posts in the archives.

	* merge.c (sec_merge_emit): Tidy.  Check for bfd_zmalloc errors.
	Write trailing padding.

Index: bfd/merge.c
===================================================================
RCS file: /cvs/src/src/bfd/merge.c,v
retrieving revision 1.23
diff -u -p -r1.23 merge.c
--- bfd/merge.c	14 Apr 2005 00:27:20 -0000	1.23
+++ bfd/merge.c	14 Apr 2005 02:00:47 -0000
@@ -288,24 +288,27 @@ sec_merge_emit (bfd *abfd, struct sec_me
 {
   struct sec_merge_sec_info *secinfo = entry->secinfo;
   asection *sec = secinfo->sec;
-  char *pad = "";
+  char *pad = NULL;
   bfd_size_type off = 0;
   int alignment_power = sec->output_section->alignment_power;
 
   if (alignment_power)
-    pad = bfd_zmalloc ((bfd_size_type) 1 << alignment_power);
+    {
+      pad = bfd_zmalloc ((bfd_size_type) 1 << alignment_power);
+      if (pad == NULL)
+	return FALSE;
+    }
 
   for (; entry != NULL && entry->secinfo == secinfo; entry = entry->next)
     {
-      register const char *str;
-      register size_t len;
+      const char *str;
+      bfd_size_type len;
 
-      len = off & (entry->alignment - 1);
-      if (len)
+      len = -off & (entry->alignment - 1);
+      if (len != 0)
 	{
-	  len = entry->alignment - len;
 	  if (bfd_bwrite (pad, len, abfd) != len)
-	    break;
+	    goto err;
 	  off += len;
 	}
 
@@ -313,15 +316,25 @@ sec_merge_emit (bfd *abfd, struct sec_me
       len = entry->len;
 
       if (bfd_bwrite (str, len, abfd) != len)
-	break;
+	goto err;
 
       off += len;
     }
 
-  if (alignment_power)
+  /* Trailing alignment needed?  */
+  off = sec->size - off;
+  if (off != 0
+      && bfd_bwrite (pad, off, abfd) != off)
+    goto err;
+
+  if (pad != NULL)
     free (pad);
+  return TRUE;
 
-  return entry == NULL || entry->secinfo != secinfo;
+ err:
+  if (pad != NULL)
+    free (pad);
+  return FALSE;
 }
 
 /* Register a SEC_MERGE section as a candidate for merging.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre