> On 9 Feb 2017, at 21:31, Adhemerval Zanella <adhemerval.zane...@linaro.org> > wrote: > > Hi all, > > While testing glibc on the kindly provided T5 machine from Debian environment, > I started to see some strange issues on sparc64 where glibc is failing on > mostly static tests. > > Funny thing is I checked the latest working revision I used to update 2.25 > release page [1] and now the tests that used to pass are now failing. In > fact I checked even the 2.23 and 2.24 glibc releases and both show the same > issues as master branch, so I am almost ruling out a glibc regression (which > was my first idea). > > I noted that the machine kernel was updated (from 4.9.2-2 to 4.9.6-3), but > I am not sure if this is something to kernel. I haven't recorded the > gcc revision I used on my initial testings. The static tets are failing due > a memcpy call that issues bogus instructions: > > (gdb) r > Starting program: /home/azanella/glibc/glibc-git-build/elf/tst-tls1-static > > Program received signal SIGSEGV, Segmentation fault. > 0x0000000000000340 in ?? () > (gdb) bt > #0 0x0000000000000340 in ?? () > #1 0x0000000000101fd8 in __libc_setup_tls () at libc-tls.c:180 > #2 0x0000000000101950 in __libc_start_main (main=0x4e8, argc=<optimized > out>, argv=0x7feffffef78, init=0x4a8, fini=0x220, rtld_fini=0x0, > stack_end=0x1) > at libc-start.c:189 > #3 0x0000000000100704 in _start () at ../sysdeps/sparc/sparc64/start.S:88 > Backtrace stopped: previous frame identical to this frame (corrupt stack?) > > (gdb) up > [...] > 0x0000000000101fc8 <+344>: add %l4, %o0, %o0 > 0x0000000000101fcc <+348>: mov %i1, %o1 > 0x0000000000101fd0 <+352>: call 0x2949c0 > 0x0000000000101fd4 <+356>: stx %o0, [ %i4 + 0x20 ] > => 0x0000000000101fd8 <+360>: sethi %hi(0x4800), %g3 > > It seems 0x2949c0 is a unknown address, where it should be the memcpy one.
Do you have the .o still for this? I would be interested to see what the relocation was. One thing that has changed within the last week is enabling PIE by default in GCC, though this call is a plain PC-relative one. Regards, James