[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Strange failures on 4.9.6-3 kernel

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. 
At first I thought it was lacking of ifunc support on static build,
so I checked disabling multiarch support (--disable-multi-arch) and
later checked with a master binutils ( but without

My next plan is rebuild GCC and check if it is something related to
system installed gcc.

Any ideas what it might be?

[1] https://sourceware.org/glibc/wiki/Release/2.25

Reply to: