On Alpha the following tests (at least) fail in the test suite with segmentation faults. badsalttest nptl/tst-eintr1 nptl/tst-cancel24-static nptl/tst-cond8-static nptl/tst-mutex8-static nptl/tst-mutexpi8-static nptl/tst-sem11-static nptl/tst-sem12-static elf/tst-tls1 elf/tst-tls2 elf/tst-tls5 Tested with both gcc-4.6 (Debian 4.6.4-2+alpha) and gcc-4.7 (Debian 4.7.3-4+alpha), and with binutils 2.23.52.20130620 and linux headers (3.9.8-1) on an Alpha ES45 running Debian unstable from Debian-Ports. Running, for example, elf/tst-tls1 manually and with --direct results in the following output: set bar to 1 (LE) get sum of foo and bar (IE) = 1 get sum of foo and bar (LD)Segmentation fault and a core dump that appears to end in __get_tls_addr(): Core was generated by `/home/mjc/toolchain/glibc-build/elf/ld-linux.so.2 --library-path /home/mjc/tool'. Program terminated with signal 11, Segmentation fault. #0 __tls_get_addr (ti=0x120019704) at dl-tls.c:775 775 void *p = dtv[GET_ADDR_MODULE].pointer.val; but I could not get a full backtrace (maybe because I am not sure how to tell gdb where to load dynamic libraries from). The test suite failures extend back to version 2.16 of the libary and probably earlier (I did not test before the merge of ports with mainline).
Configuring --enable-hardcoded-path-in-tests may make it easier to use GDB with dynamically linked tests, by allowing them to be run directly rather than with ld.so --library-path (as long as that doesn't cause the test failures to go away).
Updated to newly released 2.18. Problem in tst-tls1 appears as: Starting program: /home/mjc/toolchain/glibc-build/elf/tst-tls1 --direct set bar to 1 (LE) get sum of foo and bar (IE) = 1 get sum of foo and bar (LD) Program received signal SIGSEGV, Segmentation fault. __tls_get_addr (ti=0x120019884) at dl-tls.c:775 775 void *p = dtv[GET_ADDR_MODULE].pointer.val; (gdb) bt full #0 __tls_get_addr (ti=0x120019884) at dl-tls.c:775 dtv = 0x20000027f50 p = <optimized out> #1 0x0000000120001758 in do_test () at tst-tls1.c:48 __result = 0x120019884 result = 0 ap = 0x20000027834 bp = <optimized out> #2 0x000000012000130c in main (argc=<optimized out>, argv=<optimized out>) at ../test-skeleton.c:279 direct = 1 status = <optimized out> opt = <optimized out> timeoutfactor = 1 envstr_timeoutfactor = <optimized out> (gdb) print *dtv $1 = {counter = 1, pointer = {val = 0x1, is_static = false}} (gdb) print *ti Cannot access memory at address 0x120019884 It would therefore appear that the address passed to __tls_get_addr() is incorrect. Going up once in the stack is not particularly helpful as the problem address is calculated in the macro TLS_LD(): (gdb) up #1 0x0000000120001758 in do_test () at tst-tls1.c:48 48 ap = TLS_LD (foo); Maybe disassembly might give a clue? Here it follows: (gdb) disass Dump of assembler code for function do_test: 0x0000000120001640 <+0>: ldah gp,2(t12) 0x0000000120001644 <+4>: lda gp,-21600(gp) 0x0000000120001648 <+8>: lda sp,-48(sp) 0x000000012000164c <+12>: ldah a0,-2(gp) 0x0000000120001650 <+16>: ldq t12,-32624(gp) 0x0000000120001654 <+20>: stq ra,0(sp) 0x0000000120001658 <+24>: lda a0,23440(a0) 0x000000012000165c <+28>: stq s0,8(sp) 0x0000000120001660 <+32>: stq s1,16(sp) 0x0000000120001664 <+36>: stq s2,24(sp) 0x0000000120001668 <+40>: stq s3,32(sp) 0x000000012000166c <+44>: stq s4,40(sp) 0x0000000120001670 <+48>: ldq s1,-32512(gp) 0x0000000120001674 <+52>: jsr ra,(t12),0x120001678 <do_test+56> 0x0000000120001678 <+56>: ldah gp,2(ra) 0x000000012000167c <+60>: lda t1,1 0x0000000120001680 <+64>: lda gp,-21656(gp) 0x0000000120001684 <+68>: rduniq 0x0000000120001688 <+72>: ldah a0,-2(gp) 0x000000012000168c <+76>: ldq a3,0(s1) 0x0000000120001690 <+80>: lda a0,23458(a0) 0x0000000120001694 <+84>: ldq t12,-32664(gp) 0x0000000120001698 <+88>: lda a1,1 0x000000012000169c <+92>: lda a2,27 0x00000001200016a0 <+96>: mov v0,t0 0x00000001200016a4 <+100>: lda t0,16(t0) 0x00000001200016a8 <+104>: stl t1,0(t0) 0x00000001200016ac <+108>: mov v0,s0 0x00000001200016b0 <+112>: jsr ra,(t12),0x1200016b4 <do_test+116> 0x00000001200016b4 <+116>: ldah gp,2(ra) 0x00000001200016b8 <+120>: lda s3,20 0x00000001200016bc <+124>: lda s2,16 0x00000001200016c0 <+128>: addq s0,s3,s3 0x00000001200016c4 <+132>: addq s0,s2,s2 0x00000001200016c8 <+136>: lda gp,-21716(gp) 0x00000001200016cc <+140>: ldl a1,0(s3) 0x00000001200016d0 <+144>: ldah s0,-2(gp) 0x00000001200016d4 <+148>: ldl t0,0(s2) 0x00000001200016d8 <+152>: lda s0,23489(s0) 0x00000001200016dc <+156>: ldq t12,-32752(gp) 0x00000001200016e0 <+160>: mov s0,a0 0x00000001200016e4 <+164>: addl a1,t0,a1 0x00000001200016e8 <+168>: jsr ra,(t12),0x1200016ec <do_test+172> 0x00000001200016ec <+172>: ldah gp,2(ra) 0x00000001200016f0 <+176>: ldl t0,0(s3) 0x00000001200016f4 <+180>: lda gp,-21772(gp) 0x00000001200016f8 <+184>: ldl a1,0(s2) 0x00000001200016fc <+188>: bne t0,0x1200018a8 <do_test+616> 0x0000000120001700 <+192>: cmpeq a1,0x1,t0 0x0000000120001704 <+196>: xor t0,0x1,s2 0x0000000120001708 <+200>: bne t0,0x120001728 <do_test+232> 0x000000012000170c <+204>: ldah a0,-2(gp) ---Type <return> to continue, or q <return> to quit--- 0x0000000120001710 <+208>: ldq t12,-32752(gp) 0x0000000120001714 <+212>: lda a0,23496(a0) 0x0000000120001718 <+216>: lda s2,1 0x000000012000171c <+220>: jsr ra,(t12),0x120001720 <do_test+224> 0x0000000120001720 <+224>: ldah gp,2(ra) 0x0000000120001724 <+228>: lda gp,-21824(gp) 0x0000000120001728 <+232>: ldq a3,0(s1) 0x000000012000172c <+236>: ldah a0,-2(gp) 0x0000000120001730 <+240>: ldq t12,-32664(gp) 0x0000000120001734 <+244>: lda a1,1 0x0000000120001738 <+248>: lda a2,27 0x000000012000173c <+252>: lda a0,23506(a0) 0x0000000120001740 <+256>: jsr ra,(t12),0x120001744 <do_test+260> 0x0000000120001744 <+260>: ldah gp,2(ra) 0x0000000120001748 <+264>: lda a0,-32448(gp) 0x000000012000174c <+268>: lda gp,-21860(gp) 0x0000000120001750 <+272>: ldq t12,-32648(gp) 0x0000000120001754 <+276>: jsr ra,(t12),0x120001758 <do_test+280> => 0x0000000120001758 <+280>: ldah gp,2(ra) 0x000000012000175c <+284>: lda a0,-32448(gp) 0x0000000120001760 <+288>: lda gp,-21880(gp) 0x0000000120001764 <+292>: mov v0,s4 0x0000000120001768 <+296>: ldq t12,-32648(gp) 0x000000012000176c <+300>: lda s4,4(s4) 0x0000000120001770 <+304>: jsr ra,(t12),0x120001774 <do_test+308> 0x0000000120001774 <+308>: ldah gp,2(ra) 0x0000000120001778 <+312>: mov s0,a0 0x000000012000177c <+316>: ldl a1,0(s4) 0x0000000120001780 <+320>: lda gp,-21908(gp) 0x0000000120001784 <+324>: mov v0,s3 0x0000000120001788 <+328>: lda s3,0(s3) 0x000000012000178c <+332>: ldl t0,0(s3) 0x0000000120001790 <+336>: ldq t12,-32752(gp) 0x0000000120001794 <+340>: addl a1,t0,a1 0x0000000120001798 <+344>: jsr ra,(t12),0x12000179c <do_test+348> 0x000000012000179c <+348>: ldah gp,2(ra) 0x00000001200017a0 <+352>: ldl t0,0(s4) 0x00000001200017a4 <+356>: lda gp,-21948(gp) 0x00000001200017a8 <+360>: ldl a1,0(s3) 0x00000001200017ac <+364>: bne t0,0x120001900 <do_test+704> 0x00000001200017b0 <+368>: cmpeq a1,0x1,t0 0x00000001200017b4 <+372>: cmpeq t0,0,t1 0x00000001200017b8 <+376>: or s2,t1,s2 0x00000001200017bc <+380>: bne t0,0x1200017dc <do_test+412> 0x00000001200017c0 <+384>: ldah a0,-2(gp) 0x00000001200017c4 <+388>: ldq t12,-32752(gp) 0x00000001200017c8 <+392>: lda a0,23496(a0) 0x00000001200017cc <+396>: lda s2,1 0x00000001200017d0 <+400>: jsr ra,(t12),0x1200017d4 <do_test+404> 0x00000001200017d4 <+404>: ldah gp,2(ra) 0x00000001200017d8 <+408>: lda gp,-22004(gp) 0x00000001200017dc <+412>: ldq a3,0(s1) 0x00000001200017e0 <+416>: ldah a0,-2(gp)
All of the segmentation violations seen in the test suite are now fixed by one of the two commits: 4ab6acaebd0047dc37c6493946484be9f1b4920b alpha: Fix tls-macros.h 027e32bd42314e17095ba39df82ef293f4a72c09 alpha: Fix signal thunk unwind info Thanks, now closing.