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

[Jan Kratochvil <jan.kratochvil@redhat.com>]

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

This is a bug of unwinding clone() at this PC.  IIRC even x86_64 has this or
similar CFI bug, though.


> This patch is to set another breakpoint at the end of main, so that
> main thread will hit it, and we can check the value of tlsvar then.
> It is safe and we don't have to worry about whether gdb is able to
> unwind from pthread library to main function or not.

I have to warn that it may be a bit weaker test, it never tests both threads
TLS access during the same stop, it tests only the current thread.

But it still tests the patch works so I am fine with it (not an approval).


> Is it good to you? b.t.w, this case is UNSUPPORTED on FC 20, because
> staticthreads.c can't be compiled.  I guess this case requires
> some recent version of glibc.

I do not see any unsupported case on
 * Fedora 20 x86_64 updates-testing disabled with debuginfos
 * Fedora 20 x86_64 updates-testing enabled with debuginfos
 * Fedora 20 x86_64 updates-testing enabled without debuginfos
 * Fedora Rawhide x86_64 with debuginfos
for both nat and gdbserver runs.

Sergio said he saw some problem with mktemp symbol on some Fedora but I do not
have that reproducible so I cannot fix it.


Thanks,
Jan