Re: [patch][rfc] Allow GDB to search for the right libthread_db.so.1

[Pedro Alves <pedro@codesourcery.com>]

On Friday 01 May 2009 18:02:04, Paul Pluzhnikov wrote:
> On Fri, May 1, 2009 at 9:49 AM, Daniel Jacobowitz <drow@false.org> wrote:
> 
> > Have you tried this?
> 
> Yes. It's slightly better than what I said: GDB knows about the original
> (main) thread, and the thread that crashed, but knows no other threads.
> 

> $ /home/ppluzhnikov/Archive/sourceware.org/gdb/build2/gdb/gdb
> ./thread-crash-64-v10
> GNU gdb (GDB) 6.8.50.20090501-cvs
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-unknown-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> (gdb) r
> warning: Cannot initialize thread debugging library: versions of
> libpthread and libthread_db do not match
> warning: Cannot initialize thread debugging library: versions of
> libpthread and libthread_db do not match
> [New LWP 32375]
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to LWP 32375]
> 0x00000000004005ab in fn (p=0x7fffffffda0c) at thread-crash.c:7
> 7               cp[1] = 'a'; /* crash! */
> (gdb) inf thread
> * 2 LWP 32375  0x00000000004005ab in fn (p=0x7fffffffda0c) at thread-crash.c:7
>   1 LWP 32368  0x00007ffff7939b01 in clone () from /lib/libc.so.6

This is because even though linux_handle_extended_wait keeps track of
new cloned LWPs through PTRACE_EVENT_CLONE, it only adds them to the
lwp list.  It doesn't add them to the thread list (it does so non-stop
mode, but your example is all-stop mode).

linux-nat.c doesn't implement the target_find_new_threads callback, only
linux-thread-db.c does, but  it would be easy to write a
linux-nat.c:linux_nat_find_new_threads function that adds lwps in the
lwp_list to the thread list that aren't listed already.

The tricker case is if you had just attached to a running
multi-threaded program, and thread_db debugging fails.  There'd be
no PTRACE_EVENT_CLONE for threads that are there already, of
course, so unless there's a simpler way I don't know about, you'd
have to extract the lwp list from /proc/ info.

-- 
Pedro Alves