diff options
Diffstat (limited to 'gdb/gdb.ideas')
| -rw-r--r-- | gdb/gdb.ideas | 1277 |
1 files changed, 1277 insertions, 0 deletions
diff --git a/gdb/gdb.ideas b/gdb/gdb.ideas new file mode 100644 index 0000000..96ba662 --- /dev/null +++ b/gdb/gdb.ideas @@ -0,0 +1,1277 @@ +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'. + + +
\ No newline at end of file |