Re: [patch] Fix TLS access for -static -pthread

[Pedro Alves <palves@redhat.com>]

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