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