[patch] Indirect access to GDB history variables

[patch] Indirect access to GDB history variables

[Steve Rodrigues]

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

New Feature for GDB: Programmatic access to the value history.

Problem Description: Our company has a wide variety of GDB scripts used to 
analyze problems within core files. Many of these scripts will generate values
that are useful to probe into later; however, the scripts will generate a LOT
of values, or values that aren't in sequential order (you care about, say,
every third value). GDB only lets you reference previous history value either
with absolute numbers ($10, $236) or with reference to the most recently printed value ($$, $$9, etc). It sure would be nice if there was a way to be able to
access the value history by indirecting through a variable.

Feature: This patch enables users to programmatcially access the value history
through a GDB variable, by overloading the "$$" construct to contain a variable
name. For example, if my script had printed out values $10-$27, but only every
3rd one was interesting (it was a pointer I wished to examine further), I could
do the following:

	set $i=10
	while ($i < 28)
		p *$$i
		set $i+= 3
	end

... and I'd see values of $10, $13, $16 and so on. This makes it easier to
compose scripts together when debugging.

Implementation:
The meat of the change is in parse.c (write_dollar_variable) and eval.c 
(evaluate_subexp_standard).

I introduced a new operand type, OP_LAST_INTERNALVAR, which is emitted
by write_dollar_variable (parse.c) when it sees a "$$" that is NOT
followed by digits (and not alone, which is already an OP_LAST
operand). OP_LAST_INTERNALVAR should always be followed by an
OP_INTERNALVAR operand, pointing to the GDB variable which we will
indirect through.

When evaluate_subexp_standard (eval.c) sees an OP_LAST_INTERNALVAR, we just
need to evaluate the following OP_INTERNALVAR expression and take the 
value_contents of that expression, passing the results into 
access_value_history.

We have been using this modification internally for over a year on gdb 6.2
with no problems. The patch has been verified on gdb-6.6.50.20061212
(most recent weekly build) on Linux and on gdb-6.6.50.20061127 on Solaris 5.8
(couldn't get 20061212 to build).

Testing: This has been tested by hand. I've been trying to write a test
 case but have been having no luck getting the test suite to run (due to 
old versions of Tcl/expect on the systems this was developed on).

Future Directions: The obvious next step for this is to add a variable ($#?)
which indicates the current history value count, which makes this amenable to
full scripting rather than use by hand.

ChangeLog and Patch are attached.

--Steve

-- 
Steven Rodrigues           | Lost, yesterday, somewhere between sunrise and 
Member of Technical Staff  | sunset, two golden hours, each set with sixty
Network Appliance Corp.    | diamond minutes. No reward is offered, for they
steverod@netapp.com        | are gone forever. -- Horace Mann


[-- Attachment #2: ChangeLog --]
[-- Type: text/plain, Size: 568 bytes --]

2006-10-17	Steve Rodrigues <steverod@netapp.com>
	* expression.h (enum exp_opcode): Add OP_LAST_INTERNALVAR opcode.
	* eval.c (evaluate_subexp_standard): Process a OP_LAST_INTERNALVAR
	operand to indirectly access the value history.
	* ada-lang.c (resolve_subexp): Support OP_LAST_INTERNALVAR.
	* expprint.c (print_subexp_standard): Support OP_LAST_INTERNALVAR.
	(op_name_standard): Support OP_LAST_INTERNALVAR. 
	(dump_subexp_body_standard): Support OP_LAST_INTERNALVAR.
	* parse.c (write_dollar_variable): Support '$$' to be treated as
	an OP_LAST_INTERNALVAR.
	
	
	

[-- Attachment #3: gdb66.diffs --]
[-- Type: text/plain, Size: 4291 bytes --]

--- ./gdb/ada-lang.c.orig	Thu Nov 30 16:32:29 2006
+++ ./gdb/ada-lang.c	Thu Dec 14 18:01:00 2006
@@ -2728,6 +2728,11 @@ resolve_subexp (struct expression **expp
       *pos += 3;
       break;
 
+    case OP_LAST_INTERNALVAR:
+      *pos ++;
+      nargs = 1;
+      break;
+          
     case UNOP_MEMVAL:
       *pos += 3;
       nargs = 1;
--- ./gdb/eval.c.orig	Mon Oct  9 20:17:53 2006
+++ ./gdb/eval.c	Thu Dec 14 18:01:00 2006
@@ -473,6 +473,12 @@ evaluate_subexp_standard (struct type *e
       return
 	access_value_history (longest_to_int (exp->elts[pc + 1].longconst));
 
+     case OP_LAST_INTERNALVAR:
+       {
+       arg1 = evaluate_subexp(NULL_TYPE, exp, pos, noside);
+       return access_value_history(*(int*)value_contents(arg1));
+       }
+
     case OP_REGISTER:
       {
 	int regno = longest_to_int (exp->elts[pc + 1].longconst);
--- ./gdb/expprint.c.orig	Mon Oct  9 20:17:53 2006
+++ ./gdb/expprint.c	Thu Dec 14 18:01:00 2006
@@ -151,6 +151,12 @@ print_subexp_standard (struct expression
 			internalvar_name (exp->elts[pc + 1].internalvar));
       return;
 
+     case OP_LAST_INTERNALVAR:
+       (*pos) += 2;
+       fprintf_filtered (stream, "$$%s",
+                       internalvar_name (exp->elts[pc + 1].internalvar));
+       return;
+ 
     case OP_FUNCALL:
       (*pos) += 2;
       nargs = longest_to_int (exp->elts[pc + 1].longconst);
@@ -695,6 +701,8 @@ op_name_standard (enum exp_opcode opcode
       return "OP_REGISTER";
     case OP_INTERNALVAR:
       return "OP_INTERNALVAR";
+    case OP_LAST_INTERNALVAR:
+      return "OP_LAST_INTERNALVAR";
     case OP_FUNCALL:
       return "OP_FUNCALL";
     case OP_STRING:
@@ -976,6 +984,9 @@ dump_subexp_body_standard (struct expres
       fprintf_filtered (stream, " (%s)",
 			exp->elts[elt].internalvar->name);
       elt += 2;
+      break;
+    case OP_LAST_INTERNALVAR:
+      fprintf_filtered (stream, "History element from Internal var");
       break;
     case OP_FUNCALL:
       {
--- ./gdb/expression.h.orig	Mon Oct  9 20:17:53 2006
+++ ./gdb/expression.h	Thu Dec 14 18:01:00 2006
@@ -174,6 +174,12 @@ enum exp_opcode
     /* OP_INTERNALVAR is followed by an internalvar ptr in the next exp_element.
        With another OP_INTERNALVAR at the end, this makes three exp_elements.  */
     OP_INTERNALVAR,
+    
+    /* OP_LAST_INTERNALVAR is used for accessing the history programmatically.
+       It is followed by an internalvar ptr in the next exp_element.
+       With another OP_LAST_INTERNALVAR at the end, this makes three 
+       exp_elements. */
+    OP_LAST_INTERNALVAR,
 
     /* OP_FUNCALL is followed by an integer in the next exp_element.
        The integer is the number of args to the function call.
--- ./gdb/parse.c.orig	Sat Nov 18 15:54:32 2006
+++ ./gdb/parse.c	Thu Dec 14 18:01:00 2006
@@ -476,6 +476,7 @@ write_dollar_variable (struct stoken str
 {
   struct symbol *sym = NULL;
   struct minimal_symbol *msym = NULL;
+  int stroff = 1;
 
   /* Handle the tokens $digits; also $ (short for $0) and $$ (short for $$1)
      and $$digits (equivalent to $<-digits> if you could type that). */
@@ -487,7 +488,7 @@ write_dollar_variable (struct stoken str
   if (str.length >= 2 && str.ptr[1] == '$')
     {
       negate = 1;
-      i = 2;
+      i = stroff = 2;
     }
   if (i == str.length)
     {
@@ -536,11 +537,17 @@ write_dollar_variable (struct stoken str
       return;
     }
 
-  /* Any other names starting in $ are debugger internal variables.  */
+  /* Any other names starting in $ are debugger internal variables.  
+     A 'negated' internal variable should be treated as an indirect
+     history reference, which adds another LAST_INTERNALVAR opcode */
 
   write_exp_elt_opcode (OP_INTERNALVAR);
-  write_exp_elt_intern (lookup_internalvar (copy_name (str) + 1));
+  write_exp_elt_intern (lookup_internalvar (copy_name (str) + stroff));
   write_exp_elt_opcode (OP_INTERNALVAR);
+
+  if (negate) 
+       write_exp_elt_opcode (OP_LAST_INTERNALVAR);
+
   return;
 handle_last:
   write_exp_elt_opcode (OP_LAST);
@@ -904,6 +911,10 @@ operator_length_standard (struct express
       oplen = 3;
       break;
 
+    case OP_LAST_INTERNALVAR:
+      oplen = 1;
+      args  = 1;
+      break;
     case OP_COMPLEX:
       oplen = 1;
       args = 2;

Re: [patch] Indirect access to GDB history variables

[Eli Zaretskii]

> Date: Thu, 14 Dec 2006 18:40:50 -0800
> From: Steve Rodrigues <steverod@netapp.com>
> Cc: Steve Rodrigues <steverod@netapp.com>
> 
> New Feature for GDB: Programmatic access to the value history.
> 
> Problem Description: Our company has a wide variety of GDB scripts used to 
> analyze problems within core files. Many of these scripts will generate values
> that are useful to probe into later; however, the scripts will generate a LOT
> of values, or values that aren't in sequential order (you care about, say,
> every third value). GDB only lets you reference previous history value either
> with absolute numbers ($10, $236) or with reference to the most recently printed value ($$, $$9, etc). It sure would be nice if there was a way to be able to
> access the value history by indirecting through a variable.

Why can't you put the values you are interested in into a named
variable, like $foo, and use that?

> Feature: This patch enables users to programmatcially access the value history
> through a GDB variable, by overloading the "$$" construct to contain a variable
> name. For example, if my script had printed out values $10-$27, but only every
> 3rd one was interesting (it was a pointer I wished to examine further), I could
> do the following:
> 
> 	set $i=10
> 	while ($i < 28)
> 		p *$$i
> 		set $i+= 3
> 	end
> 
> ... and I'd see values of $10, $13, $16 and so on. This makes it easier to
> compose scripts together when debugging.

Thanks.

If this patch is accepted, I will request you to write a patch for
the manual to describe this feature.  It should also be mentioned in
NEWS.

Re: [patch] Indirect access to GDB history variables

[Daniel Jacobowitz]

On Thu, Dec 14, 2006 at 06:40:50PM -0800, Steve Rodrigues wrote:
> Feature: This patch enables users to programmatcially access the value history
> through a GDB variable, by overloading the "$$" construct to contain a variable
> name. For example, if my script had printed out values $10-$27, but only every
> 3rd one was interesting (it was a pointer I wished to examine further), I could
> do the following:
> 
> 	set $i=10
> 	while ($i < 28)
> 		p *$$i
> 		set $i+= 3
> 	end
> 
> ... and I'd see values of $10, $13, $16 and so on. This makes it easier to
> compose scripts together when debugging.

I've got to say I don't like it much :-(  But the reason isn't your
fault; in fact, as CLI extensions go, this is pretty elegant.

Changing the CLI is touchy because of how weakly specified it is.
An example of how the weak specification leaves us grasping at syntax:
this introduces something which you can do with "$i" that you can't do
with "$1", because $$i and $$1 would mean different things.

I think that we should take the long-postponed jump to embedding
scripting languages, rather than adding more complexity to the existing
CLI.  Maybe I'll take another stab at that this weekend.

If others disagree, though, I could be easily persuaded.

> Testing: This has been tested by hand. I've been trying to write a test
>  case but have been having no luck getting the test suite to run (due to 
> old versions of Tcl/expect on the systems this was developed on).

If we do go forward with this patch, I'd be happy to help you with a
test case (or with getting the testsuite going).

-- 
Daniel Jacobowitz
CodeSourcery

Re: [patch] Indirect access to GDB history variables

[Eli Zaretskii]

> Date: Sat, 16 Dec 2006 12:10:25 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb-patches@sources.redhat.com
> 
> Changing the CLI is touchy because of how weakly specified it is.

Do we have a substantial body of test cases for CLI in the test suite?
If we do, and if this change doesn't break anything there, I think we
can reasonably expect it to be safe.

> I think that we should take the long-postponed jump to embedding
> scripting languages, rather than adding more complexity to the existing
> CLI.

If we leave the current CLI available in non-interactive sessions, and
if the embedded language will satisfy Steve's needs, I'm for it.  But
I fear that agreeing on the language will take time, in which case
postponing this change will be just that.

> Maybe I'll take another stab at that this weekend.

Thanks.

Re: [patch] Indirect access to GDB history variables

[Daniel Jacobowitz]

On Sat, Dec 16, 2006 at 08:40:02PM +0200, Eli Zaretskii wrote:
> > Changing the CLI is touchy because of how weakly specified it is.
> 
> Do we have a substantial body of test cases for CLI in the test suite?
> If we do, and if this change doesn't break anything there, I think we
> can reasonably expect it to be safe.

I'm worried primarily about interactions with the expression parser,
which changes for every language we support.  I don't know if the test
coverage is adequate or not.

> > I think that we should take the long-postponed jump to embedding
> > scripting languages, rather than adding more complexity to the existing
> > CLI.
> 
> If we leave the current CLI available in non-interactive sessions, and

Definitely.  I don't suggest removing anything here.

> if the embedded language will satisfy Steve's needs, I'm for it.  But
> I fear that agreeing on the language will take time, in which case
> postponing this change will be just that.

It may be so.  My tentative plan was to offer a selection, probably
Perl and Python and Guile; once the common infrastructure is in place,
it's really not hard to add languages and enable them at configure
time.  The alternative would be to add only Guile, since that's the
language the FSF officially recommends for such things - I don't want
to take that alternative, though, since I'm practically useless in
Guile.  I have implemented Guile embedding, by the way, though never
finished it up.

Just musing, for the moment.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [patch] Indirect access to GDB history variables

[Eli Zaretskii]

> Date: Sat, 16 Dec 2006 13:45:08 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: steverod@netapp.com, gdb-patches@sources.redhat.com
> 
> > if the embedded language will satisfy Steve's needs, I'm for it.  But
> > I fear that agreeing on the language will take time, in which case
> > postponing this change will be just that.
> 
> It may be so.  My tentative plan was to offer a selection, probably
> Perl and Python and Guile; once the common infrastructure is in place,
> it's really not hard to add languages and enable them at configure
> time.  The alternative would be to add only Guile, since that's the
> language the FSF officially recommends for such things - I don't want
> to take that alternative, though, since I'm practically useless in
> Guile.  I have implemented Guile embedding, by the way, though never
> finished it up.

I have no objections for the list of languages you suggested.

We could also just accept Steve's patch and see if anyone hollers.
The next release is still far away, so we have enough to time to see
if something breaks as the result.

Re: [patch] Indirect access to GDB history variables

[Steve Rodrigues]

Daniel Jacobowitz wrote on Sat, Dec 16, 2006 at 01:45:08PM -0500:
> > > I think that we should take the long-postponed jump to embedding
> > > scripting languages, rather than adding more complexity to the existing
> > > CLI.
> > 

...[further discussion]...

I assume that with the embedded scripting language, you'd allow input in a 
'interpreted' fashion; i.e. at the gdb prompt I could enter a Perl or 
Python or Guile command directly, accessing (for example, with Perl) @history or 
$history[$i]?

Would the embedded language support current CLI scripts or not?
I.e. if I have Perl-GDB, can I run my existing GDB scripts or only
Perl-ized versions of them?  (We have quite a large pile and
migrating them to something else probably won't happen, at least in
any reasonable timeframe.)

> -- 
> Daniel Jacobowitz
> CodeSourcery

Thanks,

--Steve
-- 
Steven Rodrigues           | Lost, yesterday, somewhere between sunrise and 
Member of Technical Staff  | sunset, two golden hours, each set with sixty
Network Appliance Corp.    | diamond minutes. No reward is offered, for they
steverod@netapp.com        | are gone forever. -- Horace Mann

Re: [patch] Indirect access to GDB history variables

[Daniel Jacobowitz]

On Sun, Dec 17, 2006 at 09:45:58PM -0800, Steve Rodrigues wrote:
> Daniel Jacobowitz wrote on Sat, Dec 16, 2006 at 01:45:08PM -0500:
> > > > I think that we should take the long-postponed jump to embedding
> > > > scripting languages, rather than adding more complexity to the existing
> > > > CLI.
> > > 
> 
> ...[further discussion]...
> 
> I assume that with the embedded scripting language, you'd allow input in a 
> 'interpreted' fashion; i.e. at the gdb prompt I could enter a Perl or 
> Python or Guile command directly, accessing (for example, with Perl) @history or 
> $history[$i]?

Probably not that simply, no, but there would be some interaction.
This is one of the things I don't know how it would work yet :-)

> Would the embedded language support current CLI scripts or not?
> I.e. if I have Perl-GDB, can I run my existing GDB scripts or only
> Perl-ized versions of them?  (We have quite a large pile and
> migrating them to something else probably won't happen, at least in
> any reasonable timeframe.)

Yes, definitely, no CLI support would be removed.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [patch] Indirect access to GDB history variables

[Eli Zaretskii]

> Date: Fri, 15 Dec 2006 10:25:51 -0800
> From: Steve Rodrigues <steverod@netapp.com>
> Cc: Steve Rodrigues <steverod@netapp.com>
> 
> Of course. How will I find out if the patch is accepted (watching the mailing
> list, direct email, watching the repository; anything works, I just need to 
> know what I should be doing -- this is my first patch)?

Someone will reply to you and to the list saying that the patch is
okay, and perhaps suggesting some changes in the new code.

Btw, please don't take the discussion off the mailing list.  It should
continue in public, because I'm not the only one involved in GDB
development.