This is the mail archive of the
mailing list for the GDB project.
Re: [patch] Indirect access to GDB history variables
- From: Daniel Jacobowitz <drow at false dot org>
- To: Steve Rodrigues <steverod at netapp dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Sat, 16 Dec 2006 12:10:25 -0500
- Subject: Re: [patch] Indirect access to GDB history variables
- References: <20061215024050.GA8750@linden.netapp.com>
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
> ... 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).