Re: [non-stop] 08/10 linux native support

[Daniel Jacobowitz <drow@false.org>]

On Thu, Jul 10, 2008 at 04:27:49PM +0100, Pedro Alves wrote:
> > This (the thread_db_attach_lwp version) looks reasonable to me.  Ugly,
> > but reasonable.  Why do we need the parent's data?
> 
> Due to this:
> 
>  (gdb) r&
>  Starting program: /home/pedro/gdb/tests/threads32
>  (gdb) [Thread debugging using libthread_db enabled]
>  [New Thread 0xf7df0b90 (LWP 24154)]
>  [New Thread 0xf75efb90 (LWP 24155)]
>  info threads
>    3 Thread 0xf75efb90 (LWP 24155)  (running)
>    2 Thread 0xf7df0b90 (LWP 24154)  (running)
>  * 1 LWP 24151  (running)

Why didn't this thread get identified at the shared library event,
when libthread_db was loaded?  It already existed by then, being the
main thread.

> The issue here is that have_threads returns true here:
> 
> linux-thread-db.c:thread_db_wait
> ...
>   /* If we do not know about the main thread yet, this would be a good time to
>      find it.  */
>   if (ourstatus->kind == TARGET_WAITKIND_STOPPED && !have_threads ())
>     thread_db_find_new_threads ();
> 
> ... because there are already threads that thread_db learned about,
> so we'd not look for info regarding the main thread.

Which ought to fix this too; if we identify threads as soon as
libthread_db is activated then we won't reach this situation.  If
there's other places where we add a newly created thread without
walking all threads, then they can get a call similar to the above
(that's for the static application case where we won't get a handy
shared library event for libpthread.so).

-- 
Daniel Jacobowitz
CodeSourcery