$thread convenience variable

$thread convenience variable

[Vladimir Prus]

Hello!

Is there some convenience variable that holds the number of the current
thread, or alternatively, the thread where breakpoint was hit. Such a
variable would allow me to write
 
   breakpoint foo.cpp:10 if $thread==1 || $thread==2

If I understand correctly, at the moment gdb can't specify arbitrary
condition on thread number for breakpoint. A breakpoint is either global,
or for one thread.

If such variable does not exist, does it look like a good addition?

- Volodya

Re: $thread convenience variable

[Eli Zaretskii]

> From:  Vladimir Prus <ghost@cs.msu.su>
> Date:  Mon, 30 Jan 2006 16:31:34 +0300
> 
>    breakpoint foo.cpp:10 if $thread==1 || $thread==2
> 
> If I understand correctly, at the moment gdb can't specify arbitrary
> condition on thread number for breakpoint. A breakpoint is either global,
> or for one thread.
> 
> If such variable does not exist, does it look like a good addition?

I'd support adding such a variable.

Re: $thread convenience variable

[Vladimir Prus]

On Friday 03 February 2006 13:58, Eli Zaretskii wrote:
> > From:  Vladimir Prus <ghost@cs.msu.su>
> > Date:  Mon, 30 Jan 2006 16:31:34 +0300
> >
> >    breakpoint foo.cpp:10 if $thread==1 || $thread==2
> >
> > If I understand correctly, at the moment gdb can't specify arbitrary
> > condition on thread number for breakpoint. A breakpoint is either global,
> > or for one thread.
> >
> > If such variable does not exist, does it look like a good addition?
>
> I'd support adding such a variable.

I have it working by this patch :

--- infrun.c    (revision 1696)
+++ infrun.c    (working copy)
@@ -1836,10 +1854,17 @@

       /* Don't even think about breakpoints if just proceeded over a
          breakpoint.  */
       if (stop_signal == TARGET_SIGNAL_TRAP && trap_expected)
        bpstat_clear (&stop_bpstat);
       else
        {
+
+      set_internalvar (lookup_internalvar ("thread"),
+                      value_from_longest (builtin_type_int,
+                                          (LONGEST) inferior_ptid.pid));
+

With it, the $thread variable will mean the last thread where we've stopped, 
as opposed to the current one -- that is, does not change after "thread XXX" 
command. This might be confusing to users, or might not.

Also, I'm not sure about "inferior_ptid.pid" above. For remote target (with 
multiple threads) 'pid' is the only field with reasonable value. The value of 
'tid' field is always zero. But for native target, I suppose 'pid' is the 
same for all threads in a program, but "inferior.tid" varies. I'm a bit lost 
on this one.


- Volodya

Re: $thread convenience variable

[Eli Zaretskii]

> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Fri, 3 Feb 2006 14:10:41 +0300
> Cc: gdb@sources.redhat.com
> 
> > I'd support adding such a variable.
> 
> I have it working by this patch :

Thanks, but please add its documentation to the GDB manual.

Re: $thread convenience variable

[Vladimir Prus]

On Friday 03 February 2006 14:27, Eli Zaretskii wrote:
> > From: Vladimir Prus <ghost@cs.msu.su>
> > Date: Fri, 3 Feb 2006 14:10:41 +0300
> > Cc: gdb@sources.redhat.com
> >
> > > I'd support adding such a variable.
> >
> > I have it working by this patch :
>
> Thanks, but please add its documentation to the GDB manual.

Sure, but I'm more concerned about correctness of the patch (especially pid 
vs. tid), so would rather hear comments on that before doing anything with 
the manual.

- Volodya

Re: $thread convenience variable

[Eli Zaretskii]

> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Fri, 3 Feb 2006 14:59:39 +0300
> Cc: gdb@sources.redhat.com
> 
> > Thanks, but please add its documentation to the GDB manual.
> 
> Sure, but I'm more concerned about correctness of the patch (especially pid 
> vs. tid), so would rather hear comments on that before doing anything with 
> the manual.

What I meant to say was that a code patch without an appropriate docs
patch is incomplete.  And we'd rather see complete patches for each
change.

Anyway, a patch for the manual is orthogonal to code changes, in this
case.  Whatever patch for the code you will eventually check in, the
description of this feature in the manual will not change, since you
only add a convenience variable.  So there's no reason to wait for
comments on the code patch before writing a patch for the manual.

Re: $thread convenience variable

[Andrew STUBBS]

Vladimir Prus wrote:
> With it, the $thread variable will mean the last thread where we've stopped, 
> as opposed to the current one -- that is, does not change after "thread XXX" 
> command. This might be confusing to users, or might not.

It might be better to do this in cli-script.c in the same way as 
$arg0-$arg9 and $argc. That way it would always be up to date and would 
be read-only.

Of course these substitutions currently only work within control 
structures, such as if, while or user-defined commands. (Hmmm, a quick 
test also shows they crash GDB if not used within a user-define.)

It would also not clutter 'show conv'.

Just a thought.

Andrew Stubbs

Re: $thread convenience variable

[Vladimir Prus]

On Friday 03 February 2006 16:01, Andrew STUBBS wrote:
> Vladimir Prus wrote:
> > With it, the $thread variable will mean the last thread where we've
> > stopped, as opposed to the current one -- that is, does not change after
> > "thread XXX" command. This might be confusing to users, or might not.
>
> It might be better to do this in cli-script.c in the same way as
> $arg0-$arg9 and $argc. That way it would always be up to date and would
> be read-only.

Is that technically feasible? The $thread variable must be set before the call 
to bpstat_stop_status, otherwise you can't use $thread in breakpoint 
condition. Well, you can, but when evaluating breakpoint condition you'll use 
the old value of $thread, not the number of the thread where we've stopped.

Unless cli-script.c is somehow invoked from handle_inferior_event.

- Volodya

Re: $thread convenience variable

[Andrew STUBBS]

Vladimir Prus wrote:
> Is that technically feasible? The $thread variable must be set before the call 
> to bpstat_stop_status, otherwise you can't use $thread in breakpoint 
> condition. Well, you can, but when evaluating breakpoint condition you'll use 
> the old value of $thread, not the number of the thread where we've stopped.
> 
> Unless cli-script.c is somehow invoked from handle_inferior_event.

You're quite right, cli-script.c probably isn't the place to put this 
stuff. It would convert it at the wrong time and wouldn't work. Somehow 
I got confused with attaching command scripts to the breakpoint, not 
conditions. In that case it would work.

What I really meant to say was _like_ the ones in cli-script.c. The code 
might live somewhere else.

My point was that a (read-only) substitution might be better than a 
generic convenience variable for this purpose.

Anyway, it was just a suggestion, and, thinking about it again, it 
probably would be quite difficult to get it substituted in all the right 
places at all the right times without limiting its scope somehow.

Andrew

Re: $thread convenience variable

[Daniel Jacobowitz]

On Fri, Feb 03, 2006 at 01:54:08PM +0000, Andrew STUBBS wrote:
> Vladimir Prus wrote:
> >Is that technically feasible? The $thread variable must be set before the 
> >call to bpstat_stop_status, otherwise you can't use $thread in breakpoint 
> >condition. Well, you can, but when evaluating breakpoint condition you'll 
> >use the old value of $thread, not the number of the thread where we've 
> >stopped.
> >
> >Unless cli-script.c is somehow invoked from handle_inferior_event.
> 
> You're quite right, cli-script.c probably isn't the place to put this 
> stuff. It would convert it at the wrong time and wouldn't work. Somehow 
> I got confused with attaching command scripts to the breakpoint, not 
> conditions. In that case it would work.
> 
> What I really meant to say was _like_ the ones in cli-script.c. The code 
> might live somewhere else.
> 
> My point was that a (read-only) substitution might be better than a 
> generic convenience variable for this purpose.
> 
> Anyway, it was just a suggestion, and, thinking about it again, it 
> probably would be quite difficult to get it substituted in all the right 
> places at all the right times without limiting its scope somehow.

It ought to be able to live near the rest of the internalvar code in
value.c, I expect.

But you're right that this wouldn't be easy.  If you want to implement
the simpler version (last stopped thread), I recommend naming it
something else, so that we don't get bug reports about it not following
"thread".  And that will leave the option of implementing "$thread"
open, later.

-- 
Daniel Jacobowitz
CodeSourcery

Re: $thread convenience variable

[Daniel Jacobowitz]

On Fri, Feb 03, 2006 at 01:01:40PM +0000, Andrew STUBBS wrote:
> It might be better to do this in cli-script.c in the same way as 
> $arg0-$arg9 and $argc. That way it would always be up to date and would 
> be read-only.
> 
> Of course these substitutions currently only work within control 
> structures, such as if, while or user-defined commands. (Hmmm, a quick 
> test also shows they crash GDB if not used within a user-define.)

Test case?  I tried a couple places, it didn't crash.

-- 
Daniel Jacobowitz
CodeSourcery

Re: $thread convenience variable

[Andrew STUBBS]

Daniel Jacobowitz wrote:
> On Fri, Feb 03, 2006 at 01:01:40PM +0000, Andrew STUBBS wrote:
>> It might be better to do this in cli-script.c in the same way as 
>> $arg0-$arg9 and $argc. That way it would always be up to date and would 
>> be read-only.
>>
>> Of course these substitutions currently only work within control 
>> structures, such as if, while or user-defined commands. (Hmmm, a quick 
>> test also shows they crash GDB if not used within a user-define.)
> 
> Test case?  I tried a couple places, it didn't crash.
> 

Just on the command line, not in a define:

if 1 == 1
  echo $arg0
end

Re: $thread convenience variable

[Daniel Jacobowitz]

On Tue, Feb 07, 2006 at 10:57:08AM +0000, Andrew STUBBS wrote:
> Daniel Jacobowitz wrote:
> >On Fri, Feb 03, 2006 at 01:01:40PM +0000, Andrew STUBBS wrote:
> >>It might be better to do this in cli-script.c in the same way as 
> >>$arg0-$arg9 and $argc. That way it would always be up to date and would 
> >>be read-only.
> >>
> >>Of course these substitutions currently only work within control 
> >>structures, such as if, while or user-defined commands. (Hmmm, a quick 
> >>test also shows they crash GDB if not used within a user-define.)
> >
> >Test case?  I tried a couple places, it didn't crash.
> >
> 
> Just on the command line, not in a define:
> 
> if 1 == 1
>  echo $arg0
> end

Easily fixed, will post.

-- 
Daniel Jacobowitz
CodeSourcery