[RFC] New threadnum command for breakpoints

[RFC] New threadnum command for breakpoints

[Frederic RISS]

[-- Attachment #1: Type: text/plain, Size: 1513 bytes --]

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.

This works for breakpoint conditions because "if" is special-cased in
the expression parsers to stop the parsing. At least for C(++), there
can't be any expression typed in GDB that would contain the "if"
reserved keyword, so handling it as a stop condition in the expression
parser is OK. That can't be done for "thread" because it's a valid
language identifier.

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 ?

Fred.

[-- Attachment #2: threadnum.patch --]
[-- Type: text/x-patch, Size: 2096 bytes --]


2006-07-28  Frederic Riss  <frederic.riss@st.com>

	* breakpoint.c (threadnum_command): New function.
	(_initialize_breakpoint): Register new threadnum command.
	


Index: breakpoint.c
===================================================================
RCS file: /cvs/src/src/gdb/breakpoint.c,v
retrieving revision 1.227
diff -u -p -r1.227 breakpoint.c
--- breakpoint.c	2 Jun 2006 03:43:18 -0000	1.227
+++ breakpoint.c	27 Jul 2006 20:49:28 -0000
@@ -592,6 +592,43 @@ condition_command (char *arg, int from_t
   error (_("No breakpoint number %d."), bnum);
 }
 
+/* threadnum N TID -- set thread of breakpoint N to TID.  */
+
+static void
+threadnum_command (char *arg, int from_tty)
+{
+  struct breakpoint *b;
+  char *p;
+  int bnum, threadnum;
+
+  if (arg == 0)
+    error_no_arg (_("breakpoint number"));
+
+  p = arg;
+  bnum = get_number (&p);
+  if (bnum == 0)
+    error (_("Bad breakpoint argument: '%s'"), arg);
+
+  arg = p;
+  threadnum = get_number (&p);
+  if (threadnum == 0)
+    error (_("Bad thread id argument: '%s'"), arg);
+
+  if (threadnum != -1 && !valid_thread_id (threadnum))
+    error (_("Unknown thread %d."), threadnum);
+    
+  ALL_BREAKPOINTS (b)
+    if (b->number == bnum)
+    {
+      b->thread = threadnum;
+      breakpoints_changed ();
+      breakpoint_modify_event (b->number);
+      return;
+    }
+
+  error (_("No breakpoint number %d."), bnum);
+}
+
 static void
 commands_command (char *arg, int from_tty)
 {
@@ -7796,6 +7833,12 @@ Specify breakpoint number N to break onl
 Usage is `condition N COND', where N is an integer and COND is an\n\
 expression to be evaluated whenever breakpoint N is reached."));
 
+  add_com ("threadnum", class_breakpoint, threadnum_command, _("\
+Specify breakpoint number N to break only in thread TID.\n\
+Usage is `threadnum N TID', where N is an integer and TID is a\n\
+thread identifier as printed by \"info threads\", or -1 for\n\
+any thread."));
+
   c = add_com ("tbreak", class_breakpoint, tbreak_command, _("\
 Set a temporary breakpoint.\n\
 Like \"break\" except the breakpoint is only temporary,\n\

Re: [RFC] New threadnum command for breakpoints

[Andreas Schwab]

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.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [RFC] New threadnum command for breakpoints

[Daniel Jacobowitz]

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

Re: [RFC] New threadnum command for breakpoints

[Andreas Schwab]

Daniel Jacobowitz <drow@false.org> writes:

> 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.

I agree.  "set breakpoint" may be a better place.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [RFC] New threadnum command for breakpoints

[Frederic RISS]

On Fri, 2006-07-28 at 10:13 -0400, Daniel Jacobowitz wrote:
> On Fri, Jul 28, 2006 at 03:38:41PM +0200, Frederic RISS wrote:
> > 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).

Yes. Moreover the user has always access to GDB thread ids (info
threads), but access to other process/thread information isn't enforced
by our target_ops.

I'm all in favor of this idea (mainly because it allows to test for
multiple threads for the same breakpoint), but I think it might be an
issue in some cases:
 * infrun.c detects breakpoint thread mismatch early and has code to
handle thread hops correctly. This code won't be used in case the thread
mismatch is detected only in the breakpoint condition. Couldn't that
cause some problems? (If it's not an issue, we could certainly cleanup
handle_inferior_event to remove that code)
 * I'm also a bit concerned about performance. Evaluating expressions is
heavier that just comparing thread ids. At least in the context I use
this functionality, the faster we resume, the better my system behaves.
I haven't done any real profiling on this this point might be moot. 

Fred.

Re: [RFC] New threadnum command for breakpoints

[Daniel Jacobowitz]

On Fri, Jul 28, 2006 at 04:56:03PM +0200, Frederic RISS wrote:
>  * infrun.c detects breakpoint thread mismatch early and has code to
> handle thread hops correctly. This code won't be used in case the thread
> mismatch is detected only in the breakpoint condition. Couldn't that
> cause some problems? (If it's not an issue, we could certainly cleanup
> handle_inferior_event to remove that code)

It could probably be rearranged to only happen late.

>  * I'm also a bit concerned about performance. Evaluating expressions is
> heavier that just comparing thread ids. At least in the context I use
> this functionality, the faster we resume, the better my system behaves.
> I haven't done any real profiling on this this point might be moot. 

I really don't think this will be a problem.  But if it is, we should
address it at its source - speed up the bottlenecks.  An "if $thread
== 1" test shouldn't add much, since it doesn't have any target access.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] New threadnum command for breakpoints

[Frederic RISS]

On Fri, 2006-07-28 at 11:14 -0400, Daniel Jacobowitz wrote:
> On Fri, Jul 28, 2006 at 04:56:03PM +0200, Frederic RISS wrote:
> >  * infrun.c detects breakpoint thread mismatch early and has code to
> > handle thread hops correctly. This code won't be used in case the thread
> > mismatch is detected only in the breakpoint condition. Couldn't that
> > cause some problems? (If it's not an issue, we could certainly cleanup
> > handle_inferior_event to remove that code)
> 
> It could probably be rearranged to only happen late.

I must be missing something. If thread hops have to be handled
separately, you must be able to distinguish a condition that indicates
'wrong thread' from another that just says 'wrong condition', no?

Or maybe by 'happen late' you mean later in time and not later in the
code... but still I don't see how we could keep the current code
semantics.

Fred.

Re: [RFC] New threadnum command for breakpoints

[Daniel Jacobowitz]

On Mon, Jul 31, 2006 at 10:32:24AM +0200, Frederic RISS wrote:
> On Fri, 2006-07-28 at 11:14 -0400, Daniel Jacobowitz wrote:
> > On Fri, Jul 28, 2006 at 04:56:03PM +0200, Frederic RISS wrote:
> > >  * infrun.c detects breakpoint thread mismatch early and has code to
> > > handle thread hops correctly. This code won't be used in case the thread
> > > mismatch is detected only in the breakpoint condition. Couldn't that
> > > cause some problems? (If it's not an issue, we could certainly cleanup
> > > handle_inferior_event to remove that code)
> > 
> > It could probably be rearranged to only happen late.
> 
> I must be missing something. If thread hops have to be handled
> separately, you must be able to distinguish a condition that indicates
> 'wrong thread' from another that just says 'wrong condition', no?
> 
> Or maybe by 'happen late' you mean later in time and not later in the
> code... but still I don't see how we could keep the current code
> semantics.

I have the feeling we could treat "wrong thread" and "wrong condition"
exactly identically, and everything would still work.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] New threadnum command for breakpoints

[Frederic RISS]

On Mon, 2006-07-31 at 08:53 -0400, Daniel Jacobowitz wrote:
> > I must be missing something. If thread hops have to be handled
> > separately, you must be able to distinguish a condition that indicates
> > 'wrong thread' from another that just says 'wrong condition', no?
> [..]
>
> I have the feeling we could treat "wrong thread" and "wrong condition"
> exactly identically, and everything would still work.

OK. I've got the same feeling, but given the complexity of the execution
control machinery I was reluctant to change it. 

bpstat_stop_status already checks for the thread match, so removing the
breakpoint_thread_match test in handle_inferior_event seems right and
should give us nearly identical code paths for thread tests carried out
using bp->thread or the $_gdb_thread variable. I'll follow up soon with
a patch doing this.

BTW, noone answered your request for comments about the variable name,
so I'll do the first iteration using $_gdb_thread.

Fred.

Re: [RFC] New threadnum command for breakpoints

[Frédéric Riss]

[-- Attachment #1: Type: text/plain, Size: 1507 bytes --]

Le lundi 31 juillet 2006 à 16:00 +0200, Frederic RISS a écrit :
>  I'll follow up soon with a patch doing this.

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. 

I'm still wondering about 2 things:

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.

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:
        - Add lval_internalvar_readonly 
        - Add a read_only flag to struct internalvar and check it at
        assignment time. Internal vars are already special-cased there,
        so this should be easy. Would be my solution of choice.
        - Don't create a real convenience variable, but add OP_THREADID
        to expression.h and generate it in write_dollar_var. Also add
        some API to infrun.c to export the stopped threadid.

Fred.

[-- Attachment #2: gdb_thread.patch --]
[-- Type: text/x-patch, Size: 1513 bytes --]

2006-07-31  Frederic Riss  <frederic.riss@st.com>

	* infrun.c (handle_inferior_event): Set the $_gdb_thread convenience
	variable.  Don't call breakpoint_thread_match anymore.  Suggested by
	Vladimir Prus  <vladimir@codesourcery.com>
	

Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.213
diff -u -p -r1.213 infrun.c
--- infrun.c	22 Jul 2006 14:48:03 -0000	1.213
+++ infrun.c	31 Jul 2006 19:26:33 -0000
@@ -1250,6 +1250,10 @@ handle_inferior_event (struct execution_
 
   int sw_single_step_trap_p = 0;
   int stopped_by_watchpoint = -1;	/* Mark as unknown.  */
+  static struct internalvar *gdb_thread_var = NULL;
+
+  if (gdb_thread_var == NULL)
+    gdb_thread_var = lookup_internalvar("_gdb_thread");
 
   /* Cache the last pid/waitstatus. */
   target_last_wait_ptid = ecs->ptid;
@@ -1307,6 +1311,10 @@ handle_inferior_event (struct execution_
       ui_out_text (uiout, "]\n");
     }
 
+  set_internalvar (gdb_thread_var,
+		   value_from_longest (builtin_type_int,
+				       pid_to_thread_id (ecs->ptid)));
+
   switch (ecs->ws.kind)
     {
     case TARGET_WAITKIND_LOADED:
@@ -1589,8 +1597,6 @@ handle_inferior_event (struct execution_
       if (breakpoints_inserted && breakpoint_here_p (stop_pc))
 	{
 	  ecs->random_signal = 0;
-	  if (!breakpoint_thread_match (stop_pc, ecs->ptid))
-	    thread_hop_needed = 1;
 	}
       else if (SOFTWARE_SINGLE_STEP_P () && singlestep_breakpoints_inserted_p)
 	{

[-- Attachment #3: gdb_thread_doc.patch --]
[-- Type: text/x-patch, Size: 1591 bytes --]

2006-07-31  Frederic Riss  <frederic.riss@st.com>

	* gdb.texinfo (Stopping and starting multi-thread programs): Mention
	the $_gdb_thread convenience variable.



Index: gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.345
diff -u -p -r1.345 gdb.texinfo
--- gdb.texinfo	21 Jul 2006 14:46:55 -0000	1.345
+++ gdb.texinfo	31 Jul 2006 19:22:50 -0000
@@ -4208,8 +4208,10 @@ breakpoints on all threads, or on a part
 @cindex breakpoints and threads
 @cindex thread breakpoints
 @kindex break @dots{} thread @var{threadno}
+@vindex $_gdb_thread@r{, convenience variable}
 @item break @var{linespec} thread @var{threadno}
 @itemx break @var{linespec} thread @var{threadno} if @dots{}
+@itemx break @var{linespec} if $_gdb_thread == @var{threadno} @r{[} && @dots@r{]}
 @var{linespec} specifies source lines; there are several ways of
 writing them, but the effect is always to specify some source line.
 
@@ -4231,6 +4233,15 @@ breakpoint condition, like this:
 (@value{GDBP}) break frik.c:13 thread 28 if bartab > lim
 @end smallexample
 
+Alternatively, you can use the @samp{$_gdb_thread} convenience variable in 
+the breakpoint's condition.  The @samp{$_gdb_thread} variable is set by 
+@value{GDBN} to the thread identifier of the stopped thread.  This can be used 
+for example to make a breakpoint trigger in multiple threads, like this:
+
+@smallexample
+(@value{GDBP}) break frik.c:13 if $_gdb_thread == 8 ||  $_gdb_thread == 9
+@end smallexample
+
 @end table
 
 @cindex stopped threads

Re: [RFC] New threadnum command for breakpoints

[Eli Zaretskii]

> From: =?ISO-8859-1?Q?Fr=E9d=E9ric?= Riss <frederic.riss@gmail.com>
> Cc: Daniel Jacobowitz <drow@false.org>, Andreas Schwab <schwab@suse.de>,  gdb-patches@sources.redhat.com
> Date: Mon, 31 Jul 2006 22:06:47 +0200
> 
> Here's a code patch for discussion and a tentative doco patch.

Thanks.

> 2006-07-31  Frederic Riss  <frederic.riss@st.com>
> 
> 	* gdb.texinfo (Stopping and starting multi-thread programs): Mention
> 	the $_gdb_thread convenience variable.

One minor comment to this doco patch:

> --- gdb.texinfo	21 Jul 2006 14:46:55 -0000	1.345
> +++ gdb.texinfo	31 Jul 2006 19:22:50 -0000
> @@ -4208,8 +4208,10 @@ breakpoints on all threads, or on a part
>  @cindex breakpoints and threads
>  @cindex thread breakpoints
>  @kindex break @dots{} thread @var{threadno}
> +@vindex $_gdb_thread@r{, convenience variable}

Please move this @vindex line to before the paragraph that actually
describes the feature.  This makes the index reference the right page
in the printed version of the manual.

Other than that, the documentation patch is okay with me.

Re: [RFC] New threadnum command for breakpoints

[Daniel Jacobowitz]

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

Re: [RFC] New threadnum command for breakpoints

[Frédéric Riss]

Hi !

> > 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 :-)

Yes, agreed :-). But the issue is quite interesting... trying to come up
with a model that would allow to test for multiple thread simultaneously
is a nice exercise. 
Going slightly off-topic, do you really think that reporting
simultaneous hits would be a real gain? I don't think it's so important
as long as you don't miss any of the hits. Threading isn't totally
deterministic, thus the fact that multiple threads have hit a breakpoint
at the same time is just an 'accident' and doesn't bring any additional
information to the user. Of course this reasoning requires that targets
can guarantee that you won't miss any of the hits.

Now back to real code...

> 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?

I'm not sure. The name itself looks fine to me but, speaking as a user,
I find the leading '_' a bit strange. It seems to imply something about
the variable, but it's not clear what. 
If it was a convention and all variables would share the same prefix,
then it wouldn't feel so strange. On the other side if we want to use a
common convention we've got to start somewhere.
Anyway that's just a personal feeling, and really no big deal, maybe
others could share their opinion?

Fred.

Re: [RFC] New threadnum command for breakpoints

[Frederic RISS]

Hi

On Tue, 2006-08-08 at 21:42 +0200, Frédéric Riss wrote:
> > 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?
> 
> I'm not sure. The name itself looks fine to me but, speaking as a user,
> I find the leading '_' a bit strange. It seems to imply something about
> the variable, but it's not clear what. 
> If it was a convention and all variables would share the same prefix,
> then it wouldn't feel so strange. On the other side if we want to use a
> common convention we've got to start somewhere.
> Anyway that's just a personal feeling, and really no big deal, maybe
> others could share their opinion?

Nobody seems to care. How about we go on with the current patch (modulo
the doco fix that Eli requested)? 

Current patch:
http://sourceware.org/ml/gdb-patches/2006-07/msg00434.html

Fred.

Re: [RFC] New threadnum command for breakpoints

[Frederic RISS]

ping?

> > > 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?
> > 
> > I'm not sure. The name itself looks fine to me but, speaking as a user,
> > I find the leading '_' a bit strange. It seems to imply something about
> > the variable, but it's not clear what. 
> > If it was a convention and all variables would share the same prefix,
> > then it wouldn't feel so strange. On the other side if we want to use a
> > common convention we've got to start somewhere.
> > Anyway that's just a personal feeling, and really no big deal, maybe
> > others could share their opinion?
> 
> Nobody seems to care. How about we go on with the current patch (modulo
> the doco fix that Eli requested)? 
> 
> Current patch:
> http://sourceware.org/ml/gdb-patches/2006-07/msg00434.html
> 
> Fred.
> 

Re: [RFC] New threadnum command for breakpoints

[Frederic RISS]

On Fri, 2006-07-28 at 16:03 +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.

I thought of that, but I didn't like it: it mixes breakpoint and thread
functionality in a way that doesn't seem right... but that's just a
personal feeling that we take care not to . You suggest something like:

(gdb) thread breakpoint <bp> <tid>

Anyone else prefers it this way? 

Fred.

Re: [RFC] New threadnum command for breakpoints

[Frederic RISS]

On Fri, 2006-07-28 at 16:27 +0200, Frederic RISS wrote:
> 
> I thought of that, but I didn't like it: it mixes breakpoint and
> thread
> functionality in a way that doesn't seem right... but that's just a
> personal feeling that we take care not to  
                   ^^^^^^^^^^^^^^^^^^^^^^^^^

Oops, that was lying in my copy/paste buffer and shouldn't have landed
here. It should simply read: ``but that's just a personal feeling.''