Re: [RFC] New threadnum command for breakpoints

[Daniel Jacobowitz <drow@false.org>]

On Mon, Jul 31, 2006 at 10:06:47PM +0200, Frédéric Riss wrote:
> Here's a code patch for discussion and a tentative doco patch. I've
> chosen to initialize the variable early in handle_inferior_event, so
> that it's set whatever happens. I thought that if we document it, it'd
> rather be always set and not only for breakpoint condition evaluation. 

Good choice.  My rule of thumb is that if I'd have to apologize for
something in the manual, then I implemented it wrong - this is a
perfect example of that :-)

> 1. Should it change on a user requested thread switch? That would be a
> simple patch to thread.c:switch_to_thread. But maybe documenting it as
> 'the id of the last stopped thread' wouldn't be a bad idea. I don't
> think GDB provides a way for the user to get this information (I mean
> once he has selected another thread). This way 'thread $_gdb_thread'
> would always bring you back to the stopped thread.

What worries me here is that it locks us into a one-thread-at-a-time
model.  One of the unpleasant realities of thread debugging is that
two threads can hit breakpoints simultaneously.  You can pretend to the
user that first one happened, then the other; or you can try to expose
both.  We haven't really thought about these issues.  But, hey, it's
probably going to be a major version bump if we ever do; so let's worry
about it later :-)

If you want it to be the last stopped thread, which seems reasonable,
is there a better name we could give it?  Or is $_gdb_thread
sufficiently clear?

> 2. Should we add support for read-only convenience variables? Writing in
> $_gdb_thread makes no sense... but it causes no harm either. We already
> have $bpnum in the same situation. I see some ways to support this:

I don't think we need to worry about this.

-- 
Daniel Jacobowitz
CodeSourcery