Re: [patch] Fix a crash on NULL event_thread

[Pedro Alves <pedro at codesourcery dot com>]

Hi Jan, sorry for the delay,

On Monday 15 September 2008 19:56:27, Jan Kratochvil wrote:
> > Would it be possible to add the thread to the thread list, in
> > addition to the lwp?
>
> IMO the reason for two lists is that really these two resources are
> different. You can perfectly have tracked LWPs with no corresponding thread
> structures. Attached a testcase using clone(2) which if you CTRL-C it has a
> state: (gdb) plist thread_list ptid
> $1 = {pid = 25112, lwp = 25112, tid = 0}
> (gdb) plist lwp_list ptid
> $2 = {pid = 25112, lwp = 25115, tid = 0}
> $3 = {pid = 25112, lwp = 25112, tid = 0}
>
> New thread notification will come from libthread_db but some time in
> between we have no corresponding thread structures such as they will never
> exist for standalone LWPs.

I understand the difference between LWPs and pthread threads.

A posix threads library hides the underlying threads implementation,
but that doesn't mean that we can only call "threads", things
that are visible through pthreads.  That is, in your non-pthreads
example, you're happy to call new lwps "threads", and
use CLONE_*THREAD*.

From GDB's perspective, a "thread" is an abstraction that
represents a locus of execution.  It doesn't really matter
if its comes from pthreads or using CLONE_THREAD directly.  You'll
still need to be able to see them in "info threads", and switch
between them with "thread", and GDB will have to manage thread
stepping state in them.  In fact, the new_thread_event thing is
calling "add_thread" on an LWP, that hasn't hit a thread
create event breakpoint yet.  So, we're talking about *when/where* to
call add_thread.  In your clone-thread.c example, just put a break
on child_func and let it hit to reliably trigger the
new_thread_event path.

I've been cooking some ideas about decoupling where we trigger the
[New Thread ...] notifications (currently in add_thread), from
managing the data structures, and about making GDB's core not
so agnostic of 1:1, M:N, x:y, target/thread/lwp/process child/parent
relations, but those will come later.

In the mean time, your patch preserves the old behaviour, and
looks good to me.  You'll need someone else to approve it,
though.

-- 
Pedro Alves