[patch] Indirect access to GDB history variables

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[patch] Indirect access to GDB history variables

Steve Rodrigues
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
[hidden email]        | are gone forever. -- Horace Mann


ChangeLog (580 bytes) Download Attachment
gdb66.diffs (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [patch] Indirect access to GDB history variables

Eli Zaretskii
> Date: Thu, 14 Dec 2006 18:40:50 -0800
> From: Steve Rodrigues <[hidden email]>
> Cc: Steve Rodrigues <[hidden email]>
>
> 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.
Reply | Threaded
Open this post in threaded view
|

Re: [patch] Indirect access to GDB history variables

Eli Zaretskii
In reply to this post by Steve Rodrigues
> Date: Fri, 15 Dec 2006 10:25:51 -0800
> From: Steve Rodrigues <[hidden email]>
> Cc: Steve Rodrigues <[hidden email]>
>
> 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.
Reply | Threaded
Open this post in threaded view
|

Re: [patch] Indirect access to GDB history variables

Daniel Jacobowitz-2
In reply to this post by Steve Rodrigues
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
Reply | Threaded
Open this post in threaded view
|

Re: [patch] Indirect access to GDB history variables

Eli Zaretskii
> Date: Sat, 16 Dec 2006 12:10:25 -0500
> From: Daniel Jacobowitz <[hidden email]>
> Cc: [hidden email]
>
> 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.
Reply | Threaded
Open this post in threaded view
|

Re: [patch] Indirect access to GDB history variables

Daniel Jacobowitz-2
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
Reply | Threaded
Open this post in threaded view
|

Re: [patch] Indirect access to GDB history variables

Eli Zaretskii
> Date: Sat, 16 Dec 2006 13:45:08 -0500
> From: Daniel Jacobowitz <[hidden email]>
> Cc: [hidden email], [hidden email]
>
> > 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.
Reply | Threaded
Open this post in threaded view
|

Re: [patch] Indirect access to GDB history variables

Steve Rodrigues
In reply to this post by Daniel Jacobowitz-2
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
[hidden email]        | are gone forever. -- Horace Mann
Reply | Threaded
Open this post in threaded view
|

Re: [patch] Indirect access to GDB history variables

Daniel Jacobowitz-2
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