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: 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 #include 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 +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: 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: 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 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 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 To: bug-gdb@PREP.AI.MIT.EDU Subject: convenient script *** EOOH *** Date: Sun, 6 Sep 87 12:10:34 EDT From: Robert Morris 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 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.