[patch] Fix TLS access for -static -pthread
Pedro Alves
palves@redhat.com
Thu Jun 5 15:18:00 GMT 2014
On 06/05/2014 09:06 AM, Jan Kratochvil wrote:
> On Thu, 05 Jun 2014 09:15:05 +0200, Yao Qi wrote:
> [...]
>> thread 1^M
>> [Switching to thread 1 (Thread 5784)]^M
>> #0 clone () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:62^M
>> 62 cmp r0, #0^M
>> (gdb) PASS: gdb.threads/staticthreads.exp: thread 1
>> up 10^M
>> #2 0xbe8ea7e4 in ?? ()^M
>> (gdb) FAIL: gdb.threads/staticthreads.exp: up 10
It'd be nice if this was reported to glibc upstream.
> This is a bug of unwinding clone() at this PC. IIRC even x86_64 has this or
> similar CFI bug, though.
I think it's fixed. It works here on f20:
(gdb) bt
#0 thread_function0 (arg=0x0) at threads.c:63
#1 0x000000373c807f33 in start_thread (arg=0x7ffff7fc6700) at pthread_create.c:309
#2 0x000000373bcf4ded in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(gdb)
It seems this bug ends up easily happening on new ports:
https://sourceware.org/ml/libc-ports/2012-05/msg00068.html
https://sourceware.org/ml/libc-alpha/2014-01/msg00337.html
Sounds like nobody has a test to catch this. Assuming glibc's
backtrace() makes use of CFI, glibc itself could have one.
But maybe we should be have it too - a GNU/Linux specific,
but arch-independent test that makes sure a backtrace in a thread
always stops at clone. Likewise for catching bogus frames beyond
'_start' in the main thread (with "set backtrace past-main on").
--
Pedro Alves
More information about the Gdb-patches
mailing list