🚀 go-pugleaf

Relay-Version: VMS News - V6.0 1/9/90 VAX/VMS V5.3; site kontu.utu.fi
Path: kontu.utu.fi!polaris.utu.fi!news.funet.fi!sunic!mcsun!uunet!tut.cis.ohio-state.edu!AI.MIT.EDU!rms
Newsgroups: gnu.gdb.bug
Subject: Ideas
Message-ID: <9010142031.AA07758@pogo>
From: rms@AI.MIT.EDU (Richard Stallman)
Date: 14 Oct 90 20:31:00 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Approved: bug-gdb@prep.ai.mit.edu
Lines: 27

I was reading a manual for another debugger and found the following ideas:

* Allow GDB to read macro definitions, perhaps by running cpp with the option
to dump out all macro definitions, and then teach it how to expand macros 
in expressions.

* Have "break if CONDITION" create an assertion to be tested after each
line.

* Have a way to set a breakpoint at the exit from a named function.
(This might not work on machines that use individual return
instructions, unless you want to scan the function for such
instructions.  But we could fix this by making GCC use only one common
return point when -O is not used.)

* Support constructions for referring to variables and functions in 
specified scopes.  For example, function:var for a variable in a given
function, or file:function:function for a nested function in a static
function in a given a file, and so on.

These might not make sense for automatic variables, since you have to
identify a frame to get them, not just a scope.

* Create a way to put some of the command history into a specified file
so that you can edit it and make a script.

* Add an if statement that would test an expression for nonzeroness.