Re: Strange failures on 4.9.6-3 kernel
> On 9 Feb 2017, at 21:31, Adhemerval Zanella <adhemerval.zanella@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
Reply to: