This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [non-stop] 08/10 linux native support
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