RE: Process exit in multi-process, and gdb's selected thread.

["Marc Khouzam" <marc.khouzam@ericsson.com>]

 

> -----Original Message-----
> From: gdb-patches-owner@sourceware.org 
> [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Pedro Alves
> Sent: Monday, February 16, 2009 7:59 PM
> To: gdb-patches@sourceware.org
> Cc: Marc Khouzam
> Subject: Process exit in multi-process, and gdb's selected thread.
> 
> Hi!
> 
> I've been thinking about issues related to what to do with GDB's
> notion of selected thread, if we're debugging more than one process
> simultaneously, and the current processes exits.
> 
> What would you think if GDB could get into this state,
> after a process exit? :
> 
>  (gdb) info threads
>    2 Thread 31176.31176  0x00007f0706154796 in ?? ()
> 
>  No selected thread.  See `help thread'.
>  (gdb) info inferiors
>    3 31176
>  (gdb) c
>  Continuing.
>  Cannot execute this command without a live selected thread.
>  (gdb) detach
>  The program is not being run.
>  (gdb) kill
>  The program is not being run.
>  (gdb)   
> 
> This would happen, e.g., if the current process (it was some other
> pid, not 31176) had exited or was detached from.  Keep in mind that in
> non-stop mode, we prefer that GDB doesn't switch threads behind the
> user's back while he is typing some command. This way, when the
> current thread and inferior no longer exist, GDB switches to 
> a state that
> should be safe, and the onus is on the frontend to switch to
> whatever thread it wants.
> 
> In the past, I had solved this by spreading around some hacks
> that tried to detect the current inferior exiting, and switching
> to any other random live thread, but, that turned out to be: first,
> surprising in non-stop mode, in the case mentioned above; and
> second, surprisingly difficult to get right.  I think this usually
> means that GDB shouldn't try to be smart (well, or I shouldn't).
> 
> I've tried avoiding before getting to a state where GDB has
> no thread selected, when there are threads in the thread list.  But,
> I don't think we'll be able to avoid it in the long run.  E.g., when
> GDB gains ability to load more than on program (exec) at the 
> same time,
> (say, "cat", and "grep"), even if "cat" is running already, 
> it will fell
> natural to be able to select the "grep" executable as focus, thus,
> the selected thread in that case should be "null".   (Also 
> thinking about
> the possibility of GDB being able in the future to switch to some form
> of post-or-quasi-mortem debugging mode when a process exits, 
> I'd want GDB
> to not switch threads to some other process on a process exit.)
> 
> A bit related to this, is the hack we have currently that tags a
> few commands as being "safe to apply without a valid
> selected thread".  This served its purpose when non-stop was first
> introduced, but, I think it's time we remove them, and start making
> the checks at a lower level.  They are currently done at a too high
> level currently, which ends up getting in the way many times.  We need
> more finer grained control over which operations can and can't be
> applied without a valid thread selected, so we need to push those
> checks down, more close to core code, or even to target code.

For what it's worth, I always thought it was risky to have such
a list of 'safe' commands.  It just seemed to be asking for trouble.
 
> I'm thinking that we may need to extend the =thread-selected
> notification to tell the frontend that there's no thread selected,
> and perhaps the -thread-info,current-thread-id, output too.

Your patches does not do this yet, right?
 
> What do you think of all this, am I making sense?  Or, does it
> sound like "let's hope he comes back to senses soon, for he's
> not making any"?  :-)
> 
> Here's my current patch that implements this, in case you
> have a stub around that implements multi-process (Hi Marc!).

I don't think you explicitely said it (or maybe I've read too
many emails today), but I believe you are suggesting that GDB
be allowed to be in a state where no thread is selected and
this state should be handled properly when receiving commands.

I didn't quite understand what responsibility falls on the 
frontend with this suggestion.  

I wanted to try to patch to see what you meant more clearly.
However, I think this patch applies to HEAD but HEAD does
not work with my stub yet (the -list-thread-groups --available
problem).

But I'm quite interested...

Marc