Re: [RFC] New threadnum command for breakpoints

[Daniel Jacobowitz <drow@false.org>]

On Fri, Jul 28, 2006 at 03:38:41PM +0200, Frederic RISS wrote:
> Hello,
> 
> I recently got really frustrated that I couldn't set thread-specific
> breakpoints when using the "*<addr>" linespec location. The reason for
> this has been discussed already, but I can't seem to find the thread in
> the archives. Basically, the "*<addr>" notation treats <addr> as an
> expression and the expression parser emits a parse error if you add
> 'thread xxx' to the line.

Here it is:
  http://sourceware.org/ml/gdb-patches/2005-04/msg00092.html

> The attached patch doesn't try to solve the parsing issue, but it simply
> adds a 'threadnum' command that one can use to (un)set the thread of a
> particular breakpoint. I'm not sure about the command name, because it
> will conflict with the thread command. Suggestions appreciated. I also
> wonder if new CLI commands should be added only in the 'cli' subdir?
> 
> Of course, the patch is missing a doco part and maybe testsuite
> coverage, but I thought I'd first ask if there's interest for this or if
> I missed an existing way to do it (seems quite surprising that this
> doesn't already exist).
> Maybe the alternate approach of adding a $thread variable to use in bp
> conditions ( http://www.sourceware.org/ml/gdb/2006-02/msg00017.html )
> should be implemented instead ?

I think that's a better idea.  Although, Vlad used interior_ptid.pid;
I would have thought that the better choice would be to use GDB's
internal thread numbering.  (In fact .pid wouldn't even work, that can
be the same between threads).

If you do this please don't call it $thread.  Do we have a naming
convention for new internal variables yet?  Should it be something like
$_gdb_thread?


On Fri, Jul 28, 2006 at 04:03:37PM +0200, Andreas Schwab wrote:
> Frederic RISS <frederic.riss@st.com> writes:
> 
> > The attached patch doesn't try to solve the parsing issue, but it simply
> > adds a 'threadnum' command that one can use to (un)set the thread of a
> > particular breakpoint.  I'm not sure about the command name, because it
> > will conflict with the thread command. Suggestions appreciated.
> 
> Make it a subcommand of the thread command.

Hmm, I don't like that much - it's a breakpoint functionality, not a
thread functionality.

-- 
Daniel Jacobowitz
CodeSourcery