path: root/gdb/gdb.ideas

BABYL OPTIONS:
Version: 5
Labels:
Note:   This is the header of an rmail file.
Note:   If you are seeing it in rmail,
Note:    it means the file has no messages in it.

From: mly@MICHAEL.AI.MIT.EDU (Richard Mlynarik)
To: rms@prep.ai.mit.edu
Subject: gdb suggestions (from hpux cdb)
Reply-To: mly-prep@prep.ai.mit.edu

"find-bug" command says "I can see the problem, but it will do you
good to find it yourself"

The gdb manual should explicitly state that gdb has no control over
forked (or execed or whatever) subprocesses.

I'd still like it if "delete" said what it had done.


Date: Tuesday, 13 May 1986, 00:40-EDT
From: <rms@LMI-ANGEL>
Sender: JC@LMI-ANGEL
Subject: interesting sdb features
To: rms@angel

output format p = pointer to procedure.

foo/x or foo/4x uses size of foo as size to print.

foo[1;4] to get elements 1 thru 4.

Continue to specified line number.

Interactively delete all breakpoints (asking about each one).



Command to write backtrace into a file, or even better to duplicate all
output to a file.  This could work by playing with descriptor 1,
making it a pipe to `tee'.  The original descriptor 1 is saved and
this mode can be turned off by putting it back.
  Date: Wed, 18 Feb 87 15:37:14 EST
  From: rms (Richard M. Stallman)
  Message-Id: <8702182037.AA16492@prep.ai.mit.edu>
  To: mly-prep@prep.ai.mit.edu
  In-Reply-To: <8702181913.AA16118@prep.ai.mit.edu>
  Subject: gdb "photo" command

  I don't think all this is worth the trouble to do now,
  because the right way to do it on TRIX is totally different
  and much easier.


Commands to enable and disable the autodisplays.  Associate
autodisplays with breakpoints perhaps, so they only display
at those breakpoints; this is easier than using breakpoint commands.

Remember how each breakpoint's position was specified.
Have command to reread symbol table and respecify each
breakpoint using same args (line number or function name) as before.

Have way to proceed process in background so that can then suspend
gdb but have subprocess continue


Date: Fri, 24 Jul 87 21:30:25 EDT
From: phr@PREP.AI.MIT.EDU (Paul Rubin)
To: bug-gdb@PREP.AI.MIT.EDU

After rereading the symbol table when user runs the "symbol-file"
command, when GDB notices that some of the source files are newer
it should reload them rather than just printing a message saying
they are newer.



Message-Id: <8704171941.AA05045@orville.arpa>
To: mly@prep.ai.mit.edu
Cc: raible@orville.arpa, fouts@orville.arpa, creon@orville.arpa
Subject: gdb hack/questions, etc
Date: 17 Apr 87 11:41:42 PST (Fri)
From: raible@orville.arpa


A couple of things:

1) Will gdb ever get dbx-sytly tracing?  Wouldn't it be fairly easy to add?

2) How about an xemacs gdb mode which has various windows, perhaps using
   terminal.el for generality?

3) Any word about that stupid IRIS SIGIOT problem?  Do you know of anyone
   else who has gotten IRIS subprocesses to work more reliably?

4) Below is a hack adapted from ramsdell@linus.uucp which can be pretty
   useful in gdb.  Instead of using gdb to patch extensive changes to a
   particular function, you can do the following (assuming the 50 lines
   of code below is part of your executable):
	1) create a new file (foo.c) containing the new function
	2) run cc -c foo.c
	3) in gdb, and patch in the new function as follows:

(gdb) info breakpoints
/* Load in the new object code... */
#1   y  0x00000125  in main (dyn.c line 46)
	break only if $function = funload ("foo"), 1
	silent
	echo new code for func ($function) initialized\n
	cont

/* ...and use it instead of the old code. */
#2   y  0x000001c2  in func (dyn.c line 59)
	break only if $ret = $function (a), 1
	silent
	set a = $ret
	j 60		/* func has a return on line 60 */

	This is more complicated than it has to be because of 2 bugs in v2.1:
	1) function calls in a breakpoint command list seem to abort
	   the execution of the rest of the command list.  This is
	   why all function calls are in the conditional part.
	   (gdb reference manual section 5.5).

	2) A 'return' in a command list also aborts the execution, and
	   in addition, prompts you for a y/n.
	   (gdb reference manual section 11.1).

	On the other hand, after doing 'cc -c foo.c' (which is pretty fast),
	you can simply rerun your program to check out the changes.
	This can be a big win!

The code for this is included below (compile with cc -g):
========================================================

#include <stdio.h>
#include <a.out.h>

typedef int (*intfun)();
char *myname;

intfun funload (filename)	/* Dynamically load 1st function from a .o */
     char *filename;
{
  int fd, size;
  struct exec hdr;
  char buf[100];
  intfun fun;

  /* -A => incremental loading - use dyn as the base symbol table
     -T => set the text segment origin to the following hex address
     -N => magic number 407 (text not read-only)
  */
  sprintf (buf, "ld -A %s -T %x -N %s.o -o %s -lc",
	   myname, sbrk (0), filename, filename);

  /* NOTE: if anything mallocs space between here and below, this will fail */
  system (buf);

  fd = open (filename, 0);
  read (fd, &hdr, sizeof(hdr));
  size = hdr.a_text + hdr.a_data + hdr.a_bss;

  if ((fun = (intfun) sbrk (size)) < 0)
    printf ("Couldn't find the space"), exit();

  read (fd, fun, size);		/* Load code. */
  /* NOTE: if anything mallocs space between here and above, this will fail */

  close (fd);
  return ((intfun) fun);
}
  
main (argc, argv)
     char **argv;
{
  intfun fun1, fun2;

  myname = *argv;

  fun1 = funload("fun1");
  printf ("The answer is %d.\n", (*fun1)(11) );

  fun2 = funload("fun2");
  printf ("The answer is %d.\n", (*fun2)() );
}
1,edited,,
Received: by PREP.AI.MIT.EDU; Tue, 16 Jun 87 03:12:54 EDT
Date: Tue, 16 Jun 87 03:12:54 EDT
From: rms (Richard M. Stallman)
Message-Id: <8706160712.AA07910@prep.ai.mit.edu>
To: rms
Subject: GDB ideas

*** EOOH ***
Date: Tue, 16 Jun 87 03:12:54 EDT
From: rms (Richard M. Stallman)
To: rms
Subject: GDB ideas

* Within a user-defined command, have local convenience variables,
local functions, local defined commands.

** Optionally echo commands within a user-defined command.

** Optionally record all user-typed commands in a log file.
Optionally record GDB output there too, marked as output so it
will not be executed if replayed.

* Execution commands

** Step until next branch, or next call.
(finish is step until next return).

step branch
or should it be
continue branch

** Stop on any branch, call or return
affecting ordinary step and continue commands.

stop branch

** Trace all branches, calls, returns.
This could be done by stopping on those events
and having a continue command to be executed after.

stop branch
commands branch
continue
end

** Commands to continue or step without any display after stop.
These may be useful in user-defined commands.

Have one prefix command that does this, modifying whatever other
command you might use.  For example,

silent step 5
silent cont

** Clear all breakpoint ignore-counts when inferior exits or is killed.

** Trace changes to a location (watchpoint).
Enable and disable them.

** Info command to show command-line for running the program.

* Auto-display

** Enable and disable display expressions.
Allow syntax 1d, 2d, etc. in enable, disable and delete commands.
Then there is no more need for an undisplay command.

** Displaying an auto variable should not do it in the wrong stack frame.
Either it should search for the proper stack frame to apply to
or it should deactivate itself when in the wrong frame.

* Printing

** Print an address as <file:line>+offset.

** Abbreviate initial whitespace modulo 16.

** p/x of an array should print each element with /x.

** Change the stack scan so that it has a more general idea
of what info is needed to describe a frame fully.

* Expressions

** Array slices.  Can replace @.

** %name for use of symbol names containing funny characters.

** User-defined convenience functions that can appear in expressions.

** Expression syntax to convert line number to address.

** Expression syntax to specify a name scope with an address, line number
or frame number.

Use the line number by itself, or an address with *, just as in b or l cmd:
38:foo or *0x40a:foo.  No good; the latter would be parsed as
*(0x40a:foo).

** Expression syntax to convert a frame number to its pc.
Perhaps unary %.

* Possible bugs

** Does set $pc= cause the current scope to be recalculated?
It should.

1,,
Received: by PREP.AI.MIT.EDU; Wed, 17 Jun 87 09:59:37 EDT
From: phr@ATHENA.MIT.EDU
Received: by ATHENA (5.45/4.7)
	id AA09084; Wed, 17 Jun 87 08:54:36 EDT
Received: by ORPHEUS.MIT.EDU (5.45/4.7) id AA02565; Wed, 17 Jun 87 08:54:29 EDT
Date: Wed, 17 Jun 87 08:54:29 EDT
Message-Id: <8706171254.AA02565@ORPHEUS.MIT.EDU>
To: rms@prep.ai.mit.edu
Subject: gdb suggestion
Status: RO

*** EOOH ***
From: phr@ATHENA.MIT.EDU
Date: Wed, 17 Jun 87 08:54:29 EDT
To: rms@prep.ai.mit.edu
Subject: gdb suggestion

Completion of file and function names; e.g. typing
	break XWriteBi
prints
	No such symbol: XWriteBi.
	Setting default command to "break XWriteBitmapFile"
so you can set a break at XWriteBitmapFile by hitting return a second
time.  Other interfaces ("complete to XWriteBitmapFile? (y/n)")
are also possible.


1,edited,,
Received: by PREP.AI.MIT.EDU; Wed, 24 Sep 86 16:33:11 EDT
Date: Wed, 24 Sep 86 16:33:11 EDT
From: mly (Richard Mlynarik)
Message-Id: <8609242033.AA11520@prep.ai.mit.edu>
To: rms
Cc: mly-prep
Subject: gdb gripes/suggestions/requests

*** EOOH ***
Date: Wed, 24 Sep 86 16:33:11 EDT
From: mly (Richard Mlynarik)
To: rms
Cc: mly-prep
Subject: gdb gripes/suggestions/requests

If would be really nice to have some way to do conditionals in user
  commands -- though this is really stretching the functionality of
  gdb a little too much, perhaps.  (see ~mly/e/.gdbint for some of
  the contortions I go through with || to get conditional
  evaluation...)

A -real- win wuold be some way to execute until he next function-call
  (like c-d in the cadr debugger)  This would even be useful if it
  were rather slow -- it would probably be faster than setting
  temporary breakpoints in all the functions which might be called,
  and would certainly be faster than "step"ping one's way until a
  funcall happened.

"info source" should mention what the directory search-path is (ie
  what "info dir" says) and in which directory it found each of the
  source files (and which source files it cannot locate in the
  search-path)


1,,
Received: by xcssun.Berkeley.EDU (5.57/1.25)
	id AA22869; Thu, 22 Oct 87 09:50:30 PDT
Received: from prep.ai.mit.edu by wheaties.ai.mit.edu; Thu, 22 Oct 87 12:17:59 EDT
Received: by PREP.AI.MIT.EDU; Thu, 22 Oct 87 12:21:00 EDT
Received: from pp.mcc.com by MCC.COM with TCP; Thu 22 Oct 87 10:54:41-CDT
Posted-Date: Thu, 22 Oct 87 10:55:13 CDT
Received: from big-d.aca.mcc.com by pp.mcc.com (4.12/KA70822) 
	id AA16571; Thu, 22 Oct 87 10:55:19 cdt
Return-Path: <tiemann@big-d.aca.mcc.com>
Received: by big-d.aca.mcc.com (3.2/KA70106)
	id AA04247; Thu, 22 Oct 87 10:55:13 CDT
Date: Thu, 22 Oct 87 10:55:13 CDT
From: tiemann%pp.mcc.com@mcc.com (Michael Tiemann)
Message-Id: <8710221555.AA04247@big-d.aca.mcc.com>
To: bug-gdb@prep.ai.mit.edu
Subject: expanding file names

*** EOOH ***
Posted-Date: Thu, 22 Oct 87 10:55:13 CDT
Return-Path: <tiemann@big-d.aca.mcc.com>
Date: Thu, 22 Oct 87 10:55:13 CDT
From: tiemann%pp.mcc.com@mcc.com (Michael Tiemann)
To: bug-gdb@prep.ai.mit.edu
Subject: expanding file names

When running a program, gdb thoughtfully passes the argument list
through the shell, expanding files and environment variables as
needed.  It would be nice if the same facility were added to the
command which adds directories to search paths.  For example, it would
be nice to say "dir ~/foo" .

Michael


1,,
Received: by xcssun.Berkeley.EDU (5.57/1.25)
	id AA25075; Fri, 23 Oct 87 10:42:52 PDT
Received: from prep.ai.mit.edu by wheaties.ai.mit.edu; Fri, 23 Oct 87 13:39:37 EDT
Received: by PREP.AI.MIT.EDU; Fri, 23 Oct 87 13:42:53 EDT
Received: from relay2.cs.net by RELAY.CS.NET id ac11193; 23 Oct 87 13:03 EDT
Received: from umb.edu by RELAY.CS.NET id ac05949; 23 Oct 87 13:01 EDT
Received: by umb.umb.edu; Fri, 23 Oct 87 10:18:40 EDT
Received: by ileaf.uucp (1.1/SMI-3.0DEV3)
	id AA00599; Wed, 21 Oct 87 10:56:52 EDT
Received: from marvin.io.uucp by io.uucp (1.1/SMI-3.0DEV3)
	id AA01359; Wed, 21 Oct 87 10:58:45 EDT
Received: by marvin.io.uucp (3.2/SMI-3.2)
	id AA00334; Wed, 21 Oct 87 11:02:20 EDT
Date: Wed, 21 Oct 87 11:02:20 EDT
From: Mark Dionne <io!marvin!md%ileaf.uucp%umb.umb.edu@relay.cs.net>
Message-Id: <8710211502.AA00334@marvin.io.uucp>
To: ileaf!umb!bug-gdb@prep.ai.mit.edu
Subject: gdb bug

*** EOOH ***
Date: Wed, 21 Oct 87 11:02:20 EDT
From: Mark Dionne <io!marvin!md%ileaf.uucp%umb.umb.edu@relay.cs.net>
To: ileaf!umb!bug-gdb@prep.ai.mit.edu
Subject: gdb bug

The /FMT and @ options of the "print" command seem to interact
in GDB 2.1. For example:

(gdb) p ($cmpn.buf[-1])@($cmpn.gapb - $cmpn.buf + 1)
$17 = {-16383, -24285, 55, 27944, -24285, -24285, 55, 28010, -24285,
-24285, 55, 28076, -24285, -24285, 55, 28142, -24285}
(gdb) p/x ($cmpn.buf[-1])@($cmpn.gapb - $cmpn.buf + 1)
$18 = 0xc001

I guess I see what's happening: the /x is applying to the whole
array rather than to the individual elements. Feature or bug?

	...!harvard!umb!ileaf!md	Mark Dionne, Interleaf
	  ...!sun!sunne!ileaf!md	Ten Canal Park, Cambridge, MA 02141
					(617) 577-9813 x5551



1,,
Received: by PREP.AI.MIT.EDU; Sun, 6 Sep 87 14:27:19 EDT
Message-Id: <8709061827.AA18170@prep.ai.mit.edu>
Received: from relay2.cs.net by RELAY.CS.NET id af03990; 6 Sep 87 14:22 EDT
Received: from umb.edu by RELAY.CS.NET id ab03029; 6 Sep 87 14:16 EDT
Received: by umb.umb.edu; Sun, 6 Sep 87 12:10:34 EDT
Date: Sun, 6 Sep 87 12:10:34 EDT
Received: by typo.umb.edu; Sun, 6 Sep 87 12:04:21 EDT
From: Robert Morris <ram%typo.umb.edu@RELAY.CS.NET>
To: bug-gdb@PREP.AI.MIT.EDU
Subject: convenient script

*** EOOH ***
Date: Sun, 6 Sep 87 12:10:34 EDT
From: Robert Morris <ram%typo.umb.edu@RELAY.CS.NET>
To: bug-gdb@PREP.AI.MIT.EDU
Subject: convenient script

I find it easier to maintain binaries on our heterogenous
network if I keep this trivial script in gdb source directory. Use it
if you want.


------------

#! /bin/csh -f
#	SETUP
#	setup gdb files for presently known machines
#	ram@umb.edu 
#		(ram%umb.edu@relay.cs.net if you have an incomplete mailer)
#	or ...!harvard!umb!ram
#
#	e.g.     SETUP sun3
#	note that sunX means major release X of sun software, generally
#	sun3 at this writing (gnu 18.41)
#
#	note GDB with gnuemacs 18.41 is already configured for vaxen

#		Bob Morris, UMASS-Boston 9/6/87
switch ($1)
	case "sun2":
		;
	case "sun3" : 
		set cputype="m68k";
		set inittype="suninit";
		breaksw;
	default : 
		set cputype=$1;
		set inittype=$1init;
		breaksw;
endsw
echo \#include \"m-$1.h\" > param.h
echo \#include \"$cputype-pinsn.c\" > pinsn.c
ed initialize.h <<! >& /dev/null
/init.h/
c
#include "m-$inittype.h"
.
w
q
!




1,answered,,
Received: from prep.ai.mit.edu by wheaties.ai.mit.edu; Sat, 19 Dec 87 18:18:50 EST
Received: by PREP.AI.MIT.EDU; Sat, 19 Dec 87 18:24:38 EST
Received: from big-d.aca.mcc.com by MCC.COM with TCP; Sat 19 Dec 87 17:19:48-CST
Date: Sat, 19 Dec 87 17:19:41 CST
From: tiemann@mcc.com (Michael Tiemann)
Posted-Date: Sat, 19 Dec 87 17:19:41 CST
Message-Id: <8712192319.AA26775@big-d.aca.mcc.com>
Received: by big-d.aca.mcc.com (3.2/ACA-V2.1) 
	id AA26775; Sat, 19 Dec 87 17:19:41 CST
To: rms@prep.ai.mit.edu
Subject: gdb

*** EOOH ***
Date: Sat, 19 Dec 87 17:19:41 CST
From: tiemann@mcc.com (Michael Tiemann)
Posted-Date: Sat, 19 Dec 87 17:19:41 CST
To: rms@prep.ai.mit.edu
Subject: gdb

file values.c, function unpack_field_as_long:

  val &= (1 << bitsize) - 1;

This is not as machine independent as it could be.  If you feel like
fixing this potential problem, there are many other instances to worry
about.

Michael


1,,
Received: by xcssun.Berkeley.EDU (5.57/1.25)
	id AA04771; Thu, 20 Aug 87 22:33:25 PDT
Received: from [128.52.22.14] by ucbvax.Berkeley.EDU (5.58/1.27)
	id AA07119; Thu, 20 Aug 87 00:37:04 PDT
Received: by PREP.AI.MIT.EDU; Thu, 20 Aug 87 03:37:35 EDT
Date: Thu, 20 Aug 87 03:37:35 EDT
From: rms@prep.ai.mit.edu (Richard M. Stallman)
Message-Id: <8708200737.AA15589@prep.ai.mit.edu>
To: rms@prep.ai.mit.edu
Subject: GDB changes for next version

*** EOOH ***
Date: Thu, 20 Aug 87 03:37:35 EDT
From: rms@prep.ai.mit.edu (Richard M. Stallman)
To: rms@prep.ai.mit.edu
Subject: GDB changes for next version

1. Use links, rather than editing some files, to configure it.

2. Can misc functions eval as their addresses rather than as
 a char in that address?  Is this reasonable in all cases
 given that non-functions cannot be distinguished
 and that you might use the result in various ways (arithmetic, etc.).


1,,
Received: by xcssun.Berkeley.EDU (5.57/1.25)
	id AA09136; Sat, 29 Aug 87 02:20:15 PDT
Received: from PREP.AI.MIT.EDU by ucbvax.Berkeley.EDU (5.58/1.27)
	id AA26072; Sat, 29 Aug 87 02:21:51 PDT
Received: by PREP.AI.MIT.EDU; Sat, 29 Aug 87 05:22:30 EDT
Received: by RUTGERS.EDU (5.54/1.14) with UUCP 
	id AA22247; Sat, 29 Aug 87 05:21:13 EDT
Received: from sequent.UUCP by spool.wisc.edu; Sat, 29 Aug 87 04:18:41 CDT
Received: from reed.UUCP by ogcvax.OGC.EDU (5.51/OGC_4.8)
		id AA08044; Fri, 28 Aug 87 20:06:41 PDT
Received: by reed.UUCP (5.51/5.17)
	id AA05059; Fri, 28 Aug 87 19:19:15 PDT
From: uwvax!sequent!ogcvax!reed!keith@rutgers.edu (Keith Packard)
Message-Id: <8708290219.AA05059@reed.UUCP>
To: rms@prep.ai.mit.edu
Subject: Re: GDB 
In-Reply-To: Your message of Thu, 20 Aug 87 03:39:37 EDT.
             <8708200735.AA26546@EDDIE.MIT.EDU> 
Date: Fri, 28 Aug 87 19:19:13 PDT

*** EOOH ***
From: uwvax!sequent!ogcvax!reed!keith@rutgers.edu (Keith Packard)
To: rms@prep.ai.mit.edu
Subject: Re: GDB 
In-Reply-To: Your message of Thu, 20 Aug 87 03:39:37 EDT.
             <8708200735.AA26546@EDDIE.MIT.EDU> 
Date: Fri, 28 Aug 87 19:19:13 PDT


Here is a simple test program for exibiting the trouble with signals:

-----
# include	<signal.h>

main ()
{
	int	handle ();
	int	i;
	signal (SIGALRM, handle);
	alarm (5);
	for (i = 0; i < 100000; i++)
		printf ("%d\n", i);
}

handle ()
{
	printf ("signal!\n");
	alarm (5);
}
-----

To demonstrate the problem, simply place a breakpoint before the call to
alarm and then start stepping through the program:

(gdb) break 7
(gdb) step
...
...

Eventually, the alarm call occurs and the program ends up in some
signal handling code -- unfortuantely a machine dependent location.  At this
point, because the fp has moved out of the current function (in fact on
many machines the frame is not in a consistent state at this point) gdb
assumes that a new function has started and suspends execution with another
prompt.

A reasonable solution would be to have gdb insert a breakpoint at the
expected signal return address and continue to that breakpoint -- I've
implemented this and found that it works.  There is, however, one nasty
problem -- longjmp around the suspended frame and the breakpoint is not hit
at the expected time.

Have fun...

keith packard

tektronix!reed!keith


1,,
Received: by xcssun.Berkeley.EDU (5.57/1.25)
	id AA09143; Sat, 29 Aug 87 02:24:58 PDT
Received: by neptune.Berkeley.EDU (5.57/1.25)
	id AA03738; Sat, 29 Aug 87 02:24:50 PDT
Date: Sat, 29 Aug 87 02:24:50 PDT
From: rms@neptune.berkeley.edu (Richard Stallman)
Message-Id: <8708290924.AA03738@neptune.Berkeley.EDU>
To: rms@neptune.Berkeley.EDU
Subject: GDB bug
Reply-To: rms@prep.ai.mit.edu

*** EOOH ***
Date: Sat, 29 Aug 87 02:24:50 PDT
From: rms@neptune.berkeley.edu (Richard Stallman)
To: rms@neptune.Berkeley.EDU
Subject: GDB bug
Reply-To: rms@prep.ai.mit.edu

Is there any way to make GDB, when stepping across a function call,
notice any attempt to longjump out of that call?
Perhaps an implicit breakpoint at longjump.
If longjump is called, find the pc in the jmp_buf and put
a self-deleting breakpoint there.


1,,
Received: by xcssun.Berkeley.EDU (5.57/1.25)
	id AA07976; Fri, 28 Aug 87 09:26:12 PDT
Received: from PREP.AI.MIT.EDU by ucbvax.Berkeley.EDU (5.58/1.27)
	id AA03230; Fri, 28 Aug 87 09:28:04 PDT
Received: by PREP.AI.MIT.EDU; Fri, 28 Aug 87 12:28:43 EDT
Date: Fri, 28 Aug 87 12:28:43 EDT
From: phr@prep.ai.mit.edu (Paul Rubin)
Message-Id: <8708281628.AA09926@prep.ai.mit.edu>
To: rms@prep.ai.mit.edu
Subject: gdb suggestions

*** EOOH ***
Date: Fri, 28 Aug 87 12:28:43 EDT
From: phr@prep.ai.mit.edu (Paul Rubin)
To: rms@prep.ai.mit.edu
Subject: gdb suggestions

1. I wish gdb had a command to re-read the sources so that I can edit
the program and recompile it without having to kill and restart gdb.

2. Would be nice if gdb could somehow connect the subprocess's tty channels
to a pty, so I can run gdb in an X window and the subprocess in a different
(xterm) window.

This might need hair to detect if the subprocess is running when you try
to examine variables, etc. and stop the subproc or report an error if it is.


1,,
Received: from prep.ai.mit.edu by wheaties.ai.mit.edu; Mon, 4 Apr 88 12:43:31 EDT
Received: from CCA.CCA.COM by prep.ai.mit.edu; Mon, 4 Apr 88 11:30:55 EST
Received: by CCA.CCA.COM; Mon, 4 Apr 88 12:42:16 EDT
Date: Mon, 4 Apr 88 12:42:16 EDT
From: alex@cca.cca.com (Alexis Layton)
Message-Id: <8804041642.AA28917@CCA.CCA.COM>
To: rms@prep.ai.mit.edu
Subject: Wish List for GDB
Cc: tiemann@mcc.com

*** EOOH ***
Date: Mon, 4 Apr 88 12:42:16 EDT
From: alex@cca.cca.com (Alexis Layton)
To: rms@prep.ai.mit.edu
Subject: Wish List for GDB
Cc: tiemann@mcc.com

GDB is a good debugger.  I like it.  I think it is lacking in functionality
in the following areas:

1.  "Finish this loop" capability.  If I am stepping through code and
encounter a for-, do-, or while-loop, after a few iterations I generally
get bored.  I want to be able to say "finish this loop"; i.e. continue
until the next statement after the loop is executed.  Note this is
complicated by gotos and nested loops.

2.  GDB only prints the last line of a multi-line statement which has been
continued.  Since this is often of the form

	foobar));

it is not very convenient.  When stepping through a file using next (or step),
ALL non-blank text lines (excepting perhaps close-braces?) between the last
displayed line and the current one should be displayed.

3.  If there is a way to call a function interactively, I couldn't find it
in the on-line help.  (Having neither GNU Emacs or TeX, reading the .texinfo
files is a bit tedious.)

4.  On occasion, when debugging a function with deeply nested code in a loop,
I want to have "hierarchical" breakpoints -- that is, I want certain
breakpoints automatically enabled if a certain breakpoint is triggered,
but not if it hasn't.  I haven't thought of a good design for this yet.

5.  tbreak is not temporary enough; It should delete the breakpoint, not
disable it.

6.  what about "next to linenumber", or "continue to linenumber" -- the
only difference being next single-steps and continue sets an ephemeral
breakpoint and then deletes it.  This would also make debugging large
functions easier.

7.  variable access breakpoints (break when variable changes value)

8.  should be able to use "set" to change initialization values before
"run" is issued.  Makes setting of static debugging control variables
easier.  Right now I have to break main all the time.

9.  GDB seems to be slow in reading/processing the symbol table -- can
this be improved?

10.  Preprocessor support.  Is there any way to run the command input through
the preprocessor or otherwise get a handle on defines?  Particlarly in
debugging things like ncurses, which use umpteen defines.

(E.g., "delete_line" is defined as SP->_StrCaps[28] or some such nonsense.)

Perhaps you could spawn off a CPP and then pipe the command input to it,
appropriately down-loading the included files and whatever # text was in
the C file being debugged....

Most of these comments of course apply to GDB+ as well.

Well, that's just a few of my thoughts.  Hope they give you some ideas.

				Alexis Layton
				alex@CCA.CCA.COM


1,,
Summary-line: 27-Nov  steve%next.com@relay.cs.n  #gdb
Received: from prep.ai.mit.edu by wheaties.ai.mit.edu; Wed, 2 Dec 87 16:58:16 EST
Received: by PREP.AI.MIT.EDU; Wed, 2 Dec 87 17:00:22 EST
Message-Id: <8712022200.AA09856@prep.ai.mit.edu>
Received: from relay2.cs.net by RELAY.CS.NET id ag03066; 2 Dec 87 16:06 EST
Received: from next.com by RELAY.CS.NET id ae26721; 2 Dec 87 16:00 EST
Received: from indiana.next.com by next.next.com (3.2/SMI-3.0DEV3)
	id AA08711; Fri, 27 Nov 87 10:47:36 PST
Date: Fri, 27 Nov 87 10:41:41 PST
From: steve%next.com@relay.cs.net
To: rms@prep.ai.mit.edu
Subject: gdb

*** EOOH ***
Date: Fri, 27 Nov 87 10:41:41 PST
From: steve%next.com@relay.cs.net
To: rms@prep.ai.mit.edu
Subject: gdb

   I copied it into wheaties:gdb.tar.next.Z.  The following is our "TODO" list.
An asterisk notes an entry is completed.

- objc features:
	* printing objects:
		- printing indexed instance variables.
		* implement object-print command which lists
		  class, methods, source file, etc.
		* info objects command which lists all objects.
	
	* message expression evaluation:
		* Use symbolic method name/object name.
		- Add varargs support.
	- printing instance variables:
		- When all else fails, attempt to lookup an unknown 
		  local as an instance variable (if currently in a
		  method handler/.m file).
	* breakpoints:
		- set breakpoints in object/method handler.
	* stepping:
		- stepm command that steps over _msg call into the
		  message handler when source is available.
	* printing methods:
		* info method that lists objects that implement a given
		  method.
	* list command:
		- modifiy it so that you can list the source for a given
		  object/method pair.
	- backtrace:
		- fix braindamaged backtrace (_msg doesn't maintain a6 linkage).
	- poseAs:
		- Reinitialize Obj-C-Data when poseAs is used.
- tenex:
	* Finish incremental history searches.
	* Add history search/reverse search.
	* Add \e< and \e>
	- Save macros on exit.
	- Add commands to reset/append/prepend macrofiles.
	- Add ability to read macrofiles once in emacs mode.
	- print bindings command.
	- command completion:
		- gdb commands?
		- symbol table entries?
- symbol tables:
	- Modify current .sym file information to be left in .o files and 
	  relocated by the debugger at load time.
	- Load .sym file info on demand. 
- documentation:
- mach port:
	- use shared memory.
	- multiple threads.
	- multiple tasks.
	- /dev/proc????
		- debug an already running task.
	- debug a program with minimal symbol information.
	- debugger support for shared libraries.
- misc:
	- watchpoints.
	- add a way to set evaluation scope/context to a file.
	- disassembly enhancement:
		- support symbolic names for locals and registers and
		  args.
	- macro args (for user commands).
	- case insensitivity for searches (info command/list searches).
	- by default, load symbol table with exec-file.
	- clean up structure printing.
	- assmebler source level debugging.
	- CPP info in the debugger (be able to get to #defines).
- gdbtool:
    Source windows:
      menus:
	- tag support (callee/caller ala dir).
	- break on line.
	- unbreak on line.
	- set one shot breakpoint.
	- continue until line (with/without enabling other breakpoints).
	- search forward/reverse.
	- yank text for command window.
      attributes:
	- dir-like interface where each stack frame has a window.
	  Windows can be closed and are re-created when that stack frame
	  is reached again.  If windows are too slow, beat up Leo.
	- source windows have line-numbers/breakpoint indicator/last 
	  PC in that window/current PC.
	- full dir-like tags support for bringing up new windows (not on
	  the execution stack).
	- Allow editing of source in a window (gray-scale for new lines/
	  deleted lines) so that current debugging session still works. ???
	- incremental compiles (dream on!).
    Data display windows:
	- auto display window.
	- graphic structure display.
    Stack display window:
	- stack trace display. Menu buttons:
	- up/down.
	- continue until stack level.
    Command window:
      menu:
	- evaluate selected expression.
      attributes:
- Remote debugging:
	- Add other protocols (ethernet?, shared memory).
- C Interpreter.
	- Control flow.
	- Interpret changed code.
	- Add subroutines.



1,,
Summary-line: 22-Oct  tiemann%pp.mcc.com@mcc.co  #expanding file names
Received: by xcssun.Berkeley.EDU (5.57/1.25)
	id AA22869; Thu, 22 Oct 87 09:50:30 PDT
Received: from prep.ai.mit.edu by wheaties.ai.mit.edu; Thu, 22 Oct 87 12:17:59 EDT
Received: by PREP.AI.MIT.EDU; Thu, 22 Oct 87 12:21:00 EDT
Received: from pp.mcc.com by MCC.COM with TCP; Thu 22 Oct 87 10:54:41-CDT
Posted-Date: Thu, 22 Oct 87 10:55:13 CDT
Received: from big-d.aca.mcc.com by pp.mcc.com (4.12/KA70822) 
	id AA16571; Thu, 22 Oct 87 10:55:19 cdt
Return-Path: <tiemann@big-d.aca.mcc.com>
Received: by big-d.aca.mcc.com (3.2/KA70106)
	id AA04247; Thu, 22 Oct 87 10:55:13 CDT
Date: Thu, 22 Oct 87 10:55:13 CDT
From: tiemann%pp.mcc.com@mcc.com (Michael Tiemann)
Message-Id: <8710221555.AA04247@big-d.aca.mcc.com>
To: bug-gdb@prep.ai.mit.edu
Subject: expanding file names

*** EOOH ***
Posted-Date: Thu, 22 Oct 87 10:55:13 CDT
Return-Path: <tiemann@big-d.aca.mcc.com>
Date: Thu, 22 Oct 87 10:55:13 CDT
From: tiemann%pp.mcc.com@mcc.com (Michael Tiemann)
To: bug-gdb@prep.ai.mit.edu
Subject: expanding file names

When running a program, gdb thoughtfully passes the argument list
through the shell, expanding files and environment variables as
needed.  It would be nice if the same facility were added to the
command which adds directories to search paths.  For example, it would
be nice to say "dir ~/foo" .

Michael


1, edited, answered,,
Received: by xcssun.Berkeley.EDU (5.57/1.25)
	id AA26610; Wed, 2 Mar 88 05:27:51 PST
Received: from prep.ai.mit.edu by wheaties.ai.mit.edu; Wed, 2 Mar 88 08:26:23 EST
Received: from cgl.ucsf.EDU by prep.ai.mit.edu; Wed, 2 Mar 88 08:25:58 EST
Received: by cgl.ucsf.edu (5.54/GSC4.5)
	id AA27646; Wed, 2 Mar 88 05:23:57 PST
Received: by hop.toad.com id AA00787; Wed, 2 Mar 88 05:22:55 PST
Date: Wed, 2 Mar 88 05:22:55 PST
From: hoptoad.UUCP!gnu@cgl.ucsf.edu (John Gilmore)
Message-Id: <8803021322.AA00787@hop.toad.com>
To: rms@cgl.ucsf.edu
Subject: A few things Sun dbx does that gdb doesn't...

*** EOOH ***
Date: Wed, 2 Mar 88 05:22:55 PST
From: hoptoad.UUCP!gnu@cgl.ucsf.edu (John Gilmore)
To: rms@cgl.ucsf.edu
Subject: A few things Sun dbx does that gdb doesn't...

 * gdb won't reread the executable's symbol table when its mod time
has changed.  The user has to explicitly reread it after recompiling
the software and before typing "run".

 * gdb has no command to report the current argv for "run" commands.
"info program" or "info environment" should display this info.  (dbx
doesn't do this either, but I noticed it at the same time.)


1, answered,,
Received: by xcssun.Berkeley.EDU (5.57/1.25)
	id AA14587; Tue, 16 Feb 88 16:19:12 PST
Received: from prep.ai.mit.edu by wheaties.ai.mit.edu; Tue, 16 Feb 88 19:17:21 EST
Received: from UNIX.SRI.COM by prep.ai.mit.edu; Tue, 16 Feb 88 19:08:02 EST
Received: by sri-unix.ARPA (5.31/5.14)
	id AA25586; Tue, 16 Feb 88 16:12:32 PST
From: ozona!chase@pisa.orc.olivetti.com
Received: from ozona.orc.olivetti.com by orc.uucp (3.2/SMI-3.2)
	id AA01567; Tue, 16 Feb 88 16:01:02 PST
Received: from localhost by ozona.orc.olivetti.com (3.2/SMI-3.2)
	id AA08259; Tue, 16 Feb 88 16:02:22 PST
Message-Id: <8802170002.AA08259@ozona.orc.olivetti.com>
To: rms@prep.ai.mit.edu
Subject: GDB suggestion
Reply-To: chase%orc.uucp@unix.sri.com
Date: Tue, 16 Feb 88 16:02:18 -0800

*** EOOH ***
From: ozona!chase@pisa.orc.olivetti.com
To: rms@prep.ai.mit.edu
Subject: GDB suggestion
Reply-To: chase%orc.uucp@unix.sri.com
Date: Tue, 16 Feb 88 16:02:18 -0800


Today I found myself wanting a feature in a debugger that neither GDB
nor DBX supports.  I checked the GDB documentation and could not find
it there.  This may be too Unix-specific, so you may not want to add
it.  It may also not be of general use.  Nevertheless, I will suggest
it; it's certainly easy to ignore the suggestion.

What I wanted to do was limit the datasize of a program that I was
debugging (I am debugging someone else's garbage collector, lucky
me) without also imposing that limit on the debugger.  I didn't see
any mention of such a command in either debugger's documentation.

In other news, the alleged (ansi) C and Modula library is beginning to
work.  (The garbage collector is part of the Modula-2+ half.)

David Chase
Olivetti Research Center, Menlo Park


1,,
Return-Path: <rms@wheaties.ai.mit.edu>
Received: by frosted-flakes.ai.mit.edu; Sat, 30 Apr 88 17:05:42 EDT
Date: Sat, 30 Apr 88 17:05:42 EDT
From: rms@wheaties.ai.mit.edu (Richard Stallman)
Message-Id: <8804302105.AA25303@frosted-flakes.ai.mit.edu>
To: rms
Subject: GDB idea

*** EOOH ***
Return-Path: <rms@wheaties.ai.mit.edu>
Date: Sat, 30 Apr 88 17:05:42 EDT
From: rms@wheaties.ai.mit.edu (Richard Stallman)
To: rms
Subject: GDB idea

Expressions should record the block that symbols were looked up in,
if the symbols proved not to be static,
and an auto-display should be disabled automatically when it is
not in the block where the results would be meaningful.


1,,
Received: from ai.ai.mit.edu by wheaties.ai.mit.edu; Sun, 8 May 88 12:52:31 EDT
Received: from prep.ai.mit.edu (TCP 20015020016) by AI.AI.MIT.EDU  8 May 88 05:38:21 EDT
Received: from lilac.Berkeley.EDU by prep.ai.mit.edu; Sun, 8 May 88 04:12:02 EST
Received: from web5h.berkeley.edu
	by lilac.berkeley.edu (5.54 (CFC 4.22.3)/1.16.18)
	id AA27424; Sun, 8 May 88 02:33:06 PDT
Received: by web5h.berkeley.edu (3.2/SMI-3.0DEV3.8MXl)
	id AA05599; Sun, 8 May 88 02:33:41 PDT
Date: Sun, 8 May 88 02:33:41 PDT
From: phr%widow.Berkeley.EDU@lilac.berkeley.edu
Message-Id: <8805080933.AA05599@web5h.berkeley.edu>
To: bug-gdb@prep.ai.mit.edu
Subject: suggestion (gdb 2.4): print function names

*** EOOH ***
Date: Sun, 8 May 88 02:33:41 PDT
From: phr%widow.Berkeley.EDU@lilac.berkeley.edu
To: bug-gdb@prep.ai.mit.edu
Subject: suggestion (gdb 2.4): print function names

If p is a pointer to function, "print p" should print the name
of the function that p points to, as well as the numeric value.
Dbx does this.



1,,
Received: from lilac.berkeley.edu by wheaties.ai.mit.edu; Wed, 11 May 88 23:14:39 EDT
Received: from web8e.berkeley.edu
	by lilac.berkeley.edu (5.54 (CFC 4.22.3)/1.16.18)
	id AA11864; Wed, 11 May 88 20:11:12 PDT
Received: by web8e.berkeley.edu (3.2/SMI-3.0DEV3.8MXl)
	id AA06549; Wed, 11 May 88 20:11:44 PDT
Date: Wed, 11 May 88 20:11:44 PDT
From: phr%widow.Berkeley.EDU@lilac.berkeley.edu
Message-Id: <8805120311.AA06549@web8e.berkeley.edu>
To: rms@wheaties.ai.mit.edu
Subject: gdb suggestion

*** EOOH ***
Date: Wed, 11 May 88 20:11:44 PDT
From: phr%widow.Berkeley.EDU@lilac.berkeley.edu
To: rms@wheaties.ai.mit.edu
Subject: gdb suggestion

If the process signal mask of a program is saved in the core dump,
then gdb should have a way to read it.  I have an xemacs that hangs
in a blocking read from XCreateWindow when I run it from the csh,
but works fine when run under gdb.  (Does this mean a gdb bug?).


1, answered,,
Return-Path: <tmb@wheaties.ai.mit.edu>
Received: by sugar-smacks.ai.mit.edu; Tue, 24 May 88 00:34:01 EDT
Date: Tue, 24 May 88 00:34:01 EDT
From: tmb@wheaties.ai.mit.edu (Thomas M. Breuel)
Message-Id: <8805240434.AA02268@sugar-smacks.ai.mit.edu>
To: rms
Subject: problem with gdb...

*** EOOH ***
Return-Path: <tmb@wheaties.ai.mit.edu>
Date: Tue, 24 May 88 00:34:01 EDT
From: tmb@wheaties.ai.mit.edu (Thomas M. Breuel)
To: rms
Subject: problem with gdb...

When tracing a program that forks, the breakpoints aren't removed in the
child and it dies with a trace/bpt trap. Isn't there a more proper way to
handle this?

					Thomas.


1, forwarded, answered,,
Received: from ATHENA (ATHENA.MIT.EDU) by wheaties.ai.mit.edu; Sat, 25 Jun 88 04:02:57 EDT
From: jbs@athena.mit.edu
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA21892; Sat, 25 Jun 88 04:00:11 EDT
Received: by BRIDGETOWN.MIT.EDU (5.45/4.7) id AA13640; Sat, 25 Jun 88 03:59:57 EDT
Date: Sat, 25 Jun 88 03:59:57 EDT
Message-Id: <8806250759.AA13640@BRIDGETOWN.MIT.EDU>
To: rms@wheaties.ai.mit.edu
Subject: gdb suggestion

*** EOOH ***
From: jbs@athena.mit.edu
Date: Sat, 25 Jun 88 03:59:57 EDT
To: rms@wheaties.ai.mit.edu
Subject: gdb suggestion

Debugging X toolkit stuff involves looking at structures that fill up
several screens.  GDB would be a lot easier to use if it supported
some sort of pretty-printing of these structures.

Jeff


1, forwarded,,
Received: from prep.ai.mit.edu by wheaties.ai.mit.edu; Thu, 23 Jun 88 04:32:12 EDT
Received: from ic.Berkeley.EDU by prep.ai.mit.edu; Thu, 23 Jun 88 03:19:27 EST
Received: by ic.berkeley.edu (5.57/1.28)
	id AA02077; Thu, 23 Jun 88 01:28:08 PDT
Date: Thu, 23 Jun 88 01:28:08 PDT
From: faustus@ic.berkeley.edu (Wayne A. Christopher)
Message-Id: <8806230828.AA02077@ic.berkeley.edu>
To: rms@prep.ai.mit.edu
Subject: gdb request

*** EOOH ***
Date: Thu, 23 Jun 88 01:28:08 PDT
From: faustus@ic.berkeley.edu (Wayne A. Christopher)
To: rms@prep.ai.mit.edu
Subject: gdb request

One suggestion for future versions of gdb -- the trace command of dbx is very
useful, and a lot easier to use than the "commands" feature in gdb.  Although
it's not necessary, it would be nice to have it.

	Wayne


1, forwarded,,
Return-Path: <faustus@scruff.berkeley.edu>
Received: from prep.ai.mit.edu by life.ai.mit.edu; Sun, 24 Jul 88 03:40:33 EDT
Received: from scruff.Berkeley.EDU by prep.ai.mit.edu; Sun, 24 Jul 88 02:17:27 EST
Received: by scruff.berkeley.edu (5.57/1.28)
	id AA19389; Sun, 24 Jul 88 00:35:41 PDT
Date: Sun, 24 Jul 88 00:35:41 PDT
From: faustus@scruff.berkeley.edu (Wayne A. Christopher)
Message-Id: <8807240735.AA19389@scruff.berkeley.edu>
To: rms@prep.ai.mit.edu
Subject: gdb feature

*** EOOH ***
Return-Path: <faustus@scruff.berkeley.edu>
Date: Sun, 24 Jul 88 00:35:41 PDT
From: faustus@scruff.berkeley.edu (Wayne A. Christopher)
To: rms@prep.ai.mit.edu
Subject: gdb feature

It would be nice if I could stop and background a process running under
gdb.  Now gdb lets the process get the ^Z and gives me a prompt, instead
of stopping also.

	Wayne


1,,
Return-Path: <wesommer@athena.mit.edu>
Received: from prep.ai.mit.edu by life.ai.mit.edu; Tue, 30 Aug 88 23:18:51 EDT
Received: from ATHENA.MIT.EDU by prep.ai.mit.edu; Tue, 30 Aug 88 21:44:58 EST
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA29972; Tue, 30 Aug 88 23:16:03 EDT
Received: by E40-342A-3 (5.45/4.7)
	id AA10004; Tue, 30 Aug 88 23:15:58 EDT
Date: Tue, 30 Aug 88 23:15:58 EDT
From: Bill Sommerfeld <wesommer@athena.mit.edu>
Message-Id: <8808310315.AA10004@E40-342A-3>
To: bug-gdb@prep.ai.mit.edu
Subject: SET_STACK_LIMIT_HUGE.

*** EOOH ***
Return-Path: <wesommer@athena.mit.edu>
Date: Tue, 30 Aug 88 23:15:58 EDT
From: Bill Sommerfeld <wesommer@athena.mit.edu>
To: bug-gdb@prep.ai.mit.edu
Subject: SET_STACK_LIMIT_HUGE.

I just had the pleasure of figuring out why a program which worked
under GDB failed (with a segv) when run under the shell.  It turns out
that it was allocating too much space in the stack, and dying with a
segmentation violation when it overran the stack.

I note that gdb/main.c unlimits the stack, presumably to allow gdb to
use alloca to its heart's content.  This is well and good, but in the
interests of making the execution and debugging environments
functionally identical, could it at least set the limit back down to
what it used to be when it starts the child process?

					- Bill


1, answered,,
Return-Path: <randy@wheaties.ai.mit.edu>
Received: from hobbes.ai.mit.edu by wheaties.ai.mit.edu; Thu, 1 Sep 88 23:13:03 EDT
Received: from localhost.ARPA by hobbes.ai.mit.edu; Thu, 1 Sep 88 23:08:41 est
Message-Id: <8809020408.AA09913@hobbes.ai.mit.edu>
To: rms@wheaties.ai.mit.edu (Richard Stallman)
Cc: randy@wheaties.ai.mit.edu
Subject: Re: GDB work that needs to be done 
In-Reply-To: Your message of Thu, 01 Sep 88 19:23:47 -0400.
             <8809012323.AA01639@sugar-bombs.ai.mit.edu> 
Date: Thu, 01 Sep 88 23:08:39 +0900
From: randy@wheaties.ai.mit.edu

*** EOOH ***
Return-Path: <randy@wheaties.ai.mit.edu>
To: rms@wheaties.ai.mit.edu (Richard Stallman)
Cc: randy@wheaties.ai.mit.edu
Subject: Re: GDB work that needs to be done 
In-Reply-To: Your message of Thu, 01 Sep 88 19:23:47 -0400.
             <8809012323.AA01639@sugar-bombs.ai.mit.edu> 
Date: Thu, 01 Sep 88 23:08:39 +0900
From: randy@wheaties.ai.mit.edu


Also:

5. Step until past current line or out of stack frame.


1,,
Return-Path: <rms@wheaties.ai.mit.edu>
Received: by sugar-bombs.ai.mit.edu; Fri, 2 Sep 88 12:43:28 EDT
Date: Fri, 2 Sep 88 12:43:28 EDT
From: rms@wheaties.ai.mit.edu (Richard Stallman)
Message-Id: <8809021643.AA00263@sugar-bombs.ai.mit.edu>
To: randy@wheaties.ai.mit.edu
Cc: rms
In-Reply-To: randy@wheaties.ai.mit.edu's message of Thu, 01 Sep 88 23:08:39 +0900 <8809020408.AA09913@hobbes.ai.mit.edu>
Subject: GDB work that needs to be done 

*** EOOH ***
Return-Path: <rms@wheaties.ai.mit.edu>
Date: Fri, 2 Sep 88 12:43:28 EDT
From: rms@wheaties.ai.mit.edu (Richard Stallman)
To: randy@wheaties.ai.mit.edu
Cc: rms
In-Reply-To: randy@wheaties.ai.mit.edu's message of Thu, 01 Sep 88 23:08:39 +0900 <8809020408.AA09913@hobbes.ai.mit.edu>
Subject: GDB work that needs to be done 

     Step until past current line or out of stack frame.

I think this should be a command called `until':

   until LINE    run until line LINE.
   until	 run until reach the following line.

It can work by setting a temporary (delete when hit) breakpoint
at the specified destination and then doing `finish'.