![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gdb.ideas CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / contrib / emacs-18.55 / gdb|
Return to gdb.ideas CVS log | Up to [CSRG BSD Unix] / 43BSDReno / contrib / emacs-18.55 / gdb |
1.1 ! root 1: BABYL OPTIONS: ! 2: Version: 5 ! 3: Labels: ! 4: Note: This is the header of an rmail file. ! 5: Note: If you are seeing it in rmail, ! 6: Note: it means the file has no messages in it. ! 7: ! 8: From: [email protected] (Richard Mlynarik) ! 9: To: [email protected] ! 10: Subject: gdb suggestions (from hpux cdb) ! 11: Reply-To: [email protected] ! 12: ! 13: "find-bug" command says "I can see the problem, but it will do you ! 14: good to find it yourself" ! 15: ! 16: The gdb manual should explicitly state that gdb has no control over ! 17: forked (or execed or whatever) subprocesses. ! 18: ! 19: I'd still like it if "delete" said what it had done. ! 20: ! 21: ! 22: Date: Tuesday, 13 May 1986, 00:40-EDT ! 23: From: <rms@LMI-ANGEL> ! 24: Sender: JC@LMI-ANGEL ! 25: Subject: interesting sdb features ! 26: To: rms@angel ! 27: ! 28: output format p = pointer to procedure. ! 29: ! 30: foo/x or foo/4x uses size of foo as size to print. ! 31: ! 32: foo[1;4] to get elements 1 thru 4. ! 33: ! 34: Continue to specified line number. ! 35: ! 36: Interactively delete all breakpoints (asking about each one). ! 37: ! 38: ! 39: ! 40: Command to write backtrace into a file, or even better to duplicate all ! 41: output to a file. This could work by playing with descriptor 1, ! 42: making it a pipe to `tee'. The original descriptor 1 is saved and ! 43: this mode can be turned off by putting it back. ! 44: Date: Wed, 18 Feb 87 15:37:14 EST ! 45: From: rms (Richard M. Stallman) ! 46: Message-Id: <[email protected]> ! 47: To: [email protected] ! 48: In-Reply-To: <[email protected]> ! 49: Subject: gdb "photo" command ! 50: ! 51: I don't think all this is worth the trouble to do now, ! 52: because the right way to do it on TRIX is totally different ! 53: and much easier. ! 54: ! 55: ! 56: Commands to enable and disable the autodisplays. Associate ! 57: autodisplays with breakpoints perhaps, so they only display ! 58: at those breakpoints; this is easier than using breakpoint commands. ! 59: ! 60: Remember how each breakpoint's position was specified. ! 61: Have command to reread symbol table and respecify each ! 62: breakpoint using same args (line number or function name) as before. ! 63: ! 64: Have way to proceed process in background so that can then suspend ! 65: gdb but have subprocess continue ! 66: ! 67: ! 68: Date: Fri, 24 Jul 87 21:30:25 EDT ! 69: From: [email protected] (Paul Rubin) ! 70: To: [email protected] ! 71: ! 72: After rereading the symbol table when user runs the "symbol-file" ! 73: command, when GDB notices that some of the source files are newer ! 74: it should reload them rather than just printing a message saying ! 75: they are newer. ! 76: ! 77: ! 78: ! 79: Message-Id: <[email protected]> ! 80: To: [email protected] ! 81: Cc: [email protected], [email protected], [email protected] ! 82: Subject: gdb hack/questions, etc ! 83: Date: 17 Apr 87 11:41:42 PST (Fri) ! 84: From: [email protected] ! 85: ! 86: ! 87: A couple of things: ! 88: ! 89: 1) Will gdb ever get dbx-sytly tracing? Wouldn't it be fairly easy to add? ! 90: ! 91: 2) How about an xemacs gdb mode which has various windows, perhaps using ! 92: terminal.el for generality? ! 93: ! 94: 3) Any word about that stupid IRIS SIGIOT problem? Do you know of anyone ! 95: else who has gotten IRIS subprocesses to work more reliably? ! 96: ! 97: 4) Below is a hack adapted from [email protected] which can be pretty ! 98: useful in gdb. Instead of using gdb to patch extensive changes to a ! 99: particular function, you can do the following (assuming the 50 lines ! 100: of code below is part of your executable): ! 101: 1) create a new file (foo.c) containing the new function ! 102: 2) run cc -c foo.c ! 103: 3) in gdb, and patch in the new function as follows: ! 104: ! 105: (gdb) info breakpoints ! 106: /* Load in the new object code... */ ! 107: #1 y 0x00000125 in main (dyn.c line 46) ! 108: break only if $function = funload ("foo"), 1 ! 109: silent ! 110: echo new code for func ($function) initialized\n ! 111: cont ! 112: ! 113: /* ...and use it instead of the old code. */ ! 114: #2 y 0x000001c2 in func (dyn.c line 59) ! 115: break only if $ret = $function (a), 1 ! 116: silent ! 117: set a = $ret ! 118: j 60 /* func has a return on line 60 */ ! 119: ! 120: This is more complicated than it has to be because of 2 bugs in v2.1: ! 121: 1) function calls in a breakpoint command list seem to abort ! 122: the execution of the rest of the command list. This is ! 123: why all function calls are in the conditional part. ! 124: (gdb reference manual section 5.5). ! 125: ! 126: 2) A 'return' in a command list also aborts the execution, and ! 127: in addition, prompts you for a y/n. ! 128: (gdb reference manual section 11.1). ! 129: ! 130: On the other hand, after doing 'cc -c foo.c' (which is pretty fast), ! 131: you can simply rerun your program to check out the changes. ! 132: This can be a big win! ! 133: ! 134: The code for this is included below (compile with cc -g): ! 135: ======================================================== ! 136: ! 137: #include <stdio.h> ! 138: #include <a.out.h> ! 139: ! 140: typedef int (*intfun)(); ! 141: char *myname; ! 142: ! 143: intfun funload (filename) /* Dynamically load 1st function from a .o */ ! 144: char *filename; ! 145: { ! 146: int fd, size; ! 147: struct exec hdr; ! 148: char buf[100]; ! 149: intfun fun; ! 150: ! 151: /* -A => incremental loading - use dyn as the base symbol table ! 152: -T => set the text segment origin to the following hex address ! 153: -N => magic number 407 (text not read-only) ! 154: */ ! 155: sprintf (buf, "ld -A %s -T %x -N %s.o -o %s -lc", ! 156: myname, sbrk (0), filename, filename); ! 157: ! 158: /* NOTE: if anything mallocs space between here and below, this will fail */ ! 159: system (buf); ! 160: ! 161: fd = open (filename, 0); ! 162: read (fd, &hdr, sizeof(hdr)); ! 163: size = hdr.a_text + hdr.a_data + hdr.a_bss; ! 164: ! 165: if ((fun = (intfun) sbrk (size)) < 0) ! 166: printf ("Couldn't find the space"), exit(); ! 167: ! 168: read (fd, fun, size); /* Load code. */ ! 169: /* NOTE: if anything mallocs space between here and above, this will fail */ ! 170: ! 171: close (fd); ! 172: return ((intfun) fun); ! 173: } ! 174: ! 175: main (argc, argv) ! 176: char **argv; ! 177: { ! 178: intfun fun1, fun2; ! 179: ! 180: myname = *argv; ! 181: ! 182: fun1 = funload("fun1"); ! 183: printf ("The answer is %d.\n", (*fun1)(11) ); ! 184: ! 185: fun2 = funload("fun2"); ! 186: printf ("The answer is %d.\n", (*fun2)() ); ! 187: } ! 188: 1,edited,, ! 189: Received: by PREP.AI.MIT.EDU; Tue, 16 Jun 87 03:12:54 EDT ! 190: Date: Tue, 16 Jun 87 03:12:54 EDT ! 191: From: rms (Richard M. Stallman) ! 192: Message-Id: <[email protected]> ! 193: To: rms ! 194: Subject: GDB ideas ! 195: ! 196: *** EOOH *** ! 197: Date: Tue, 16 Jun 87 03:12:54 EDT ! 198: From: rms (Richard M. Stallman) ! 199: To: rms ! 200: Subject: GDB ideas ! 201: ! 202: * Within a user-defined command, have local convenience variables, ! 203: local functions, local defined commands. ! 204: ! 205: ** Optionally echo commands within a user-defined command. ! 206: ! 207: ** Optionally record all user-typed commands in a log file. ! 208: Optionally record GDB output there too, marked as output so it ! 209: will not be executed if replayed. ! 210: ! 211: * Execution commands ! 212: ! 213: ** Step until next branch, or next call. ! 214: (finish is step until next return). ! 215: ! 216: step branch ! 217: or should it be ! 218: continue branch ! 219: ! 220: ** Stop on any branch, call or return ! 221: affecting ordinary step and continue commands. ! 222: ! 223: stop branch ! 224: ! 225: ** Trace all branches, calls, returns. ! 226: This could be done by stopping on those events ! 227: and having a continue command to be executed after. ! 228: ! 229: stop branch ! 230: commands branch ! 231: continue ! 232: end ! 233: ! 234: ** Commands to continue or step without any display after stop. ! 235: These may be useful in user-defined commands. ! 236: ! 237: Have one prefix command that does this, modifying whatever other ! 238: command you might use. For example, ! 239: ! 240: silent step 5 ! 241: silent cont ! 242: ! 243: ** Clear all breakpoint ignore-counts when inferior exits or is killed. ! 244: ! 245: ** Trace changes to a location (watchpoint). ! 246: Enable and disable them. ! 247: ! 248: ** Info command to show command-line for running the program. ! 249: ! 250: * Auto-display ! 251: ! 252: ** Enable and disable display expressions. ! 253: Allow syntax 1d, 2d, etc. in enable, disable and delete commands. ! 254: Then there is no more need for an undisplay command. ! 255: ! 256: ** Displaying an auto variable should not do it in the wrong stack frame. ! 257: Either it should search for the proper stack frame to apply to ! 258: or it should deactivate itself when in the wrong frame. ! 259: ! 260: * Printing ! 261: ! 262: ** Print an address as <file:line>+offset. ! 263: ! 264: ** Abbreviate initial whitespace modulo 16. ! 265: ! 266: ** p/x of an array should print each element with /x. ! 267: ! 268: ** Change the stack scan so that it has a more general idea ! 269: of what info is needed to describe a frame fully. ! 270: ! 271: * Expressions ! 272: ! 273: ** Array slices. Can replace @. ! 274: ! 275: ** %name for use of symbol names containing funny characters. ! 276: ! 277: ** User-defined convenience functions that can appear in expressions. ! 278: ! 279: ** Expression syntax to convert line number to address. ! 280: ! 281: ** Expression syntax to specify a name scope with an address, line number ! 282: or frame number. ! 283: ! 284: Use the line number by itself, or an address with *, just as in b or l cmd: ! 285: 38:foo or *0x40a:foo. No good; the latter would be parsed as ! 286: *(0x40a:foo). ! 287: ! 288: ** Expression syntax to convert a frame number to its pc. ! 289: Perhaps unary %. ! 290: ! 291: * Possible bugs ! 292: ! 293: ** Does set $pc= cause the current scope to be recalculated? ! 294: It should. ! 295: ! 296: 1,, ! 297: Received: by PREP.AI.MIT.EDU; Wed, 17 Jun 87 09:59:37 EDT ! 298: From: [email protected] ! 299: Received: by ATHENA (5.45/4.7) ! 300: id AA09084; Wed, 17 Jun 87 08:54:36 EDT ! 301: Received: by ORPHEUS.MIT.EDU (5.45/4.7) id AA02565; Wed, 17 Jun 87 08:54:29 EDT ! 302: Date: Wed, 17 Jun 87 08:54:29 EDT ! 303: Message-Id: <[email protected]> ! 304: To: [email protected] ! 305: Subject: gdb suggestion ! 306: Status: RO ! 307: ! 308: *** EOOH *** ! 309: From: [email protected] ! 310: Date: Wed, 17 Jun 87 08:54:29 EDT ! 311: To: [email protected] ! 312: Subject: gdb suggestion ! 313: ! 314: Completion of file and function names; e.g. typing ! 315: break XWriteBi ! 316: prints ! 317: No such symbol: XWriteBi. ! 318: Setting default command to "break XWriteBitmapFile" ! 319: so you can set a break at XWriteBitmapFile by hitting return a second ! 320: time. Other interfaces ("complete to XWriteBitmapFile? (y/n)") ! 321: are also possible. ! 322: ! 323: ! 324: 1,edited,, ! 325: Received: by PREP.AI.MIT.EDU; Wed, 24 Sep 86 16:33:11 EDT ! 326: Date: Wed, 24 Sep 86 16:33:11 EDT ! 327: From: mly (Richard Mlynarik) ! 328: Message-Id: <[email protected]> ! 329: To: rms ! 330: Cc: mly-prep ! 331: Subject: gdb gripes/suggestions/requests ! 332: ! 333: *** EOOH *** ! 334: Date: Wed, 24 Sep 86 16:33:11 EDT ! 335: From: mly (Richard Mlynarik) ! 336: To: rms ! 337: Cc: mly-prep ! 338: Subject: gdb gripes/suggestions/requests ! 339: ! 340: If would be really nice to have some way to do conditionals in user ! 341: commands -- though this is really stretching the functionality of ! 342: gdb a little too much, perhaps. (see ~mly/e/.gdbint for some of ! 343: the contortions I go through with || to get conditional ! 344: evaluation...) ! 345: ! 346: A -real- win wuold be some way to execute until he next function-call ! 347: (like c-d in the cadr debugger) This would even be useful if it ! 348: were rather slow -- it would probably be faster than setting ! 349: temporary breakpoints in all the functions which might be called, ! 350: and would certainly be faster than "step"ping one's way until a ! 351: funcall happened. ! 352: ! 353: "info source" should mention what the directory search-path is (ie ! 354: what "info dir" says) and in which directory it found each of the ! 355: source files (and which source files it cannot locate in the ! 356: search-path) ! 357: ! 358: ! 359: 1,, ! 360: Received: by xcssun.Berkeley.EDU (5.57/1.25) ! 361: id AA22869; Thu, 22 Oct 87 09:50:30 PDT ! 362: Received: from prep.ai.mit.edu by wheaties.ai.mit.edu; Thu, 22 Oct 87 12:17:59 EDT ! 363: Received: by PREP.AI.MIT.EDU; Thu, 22 Oct 87 12:21:00 EDT ! 364: Received: from pp.mcc.com by MCC.COM with TCP; Thu 22 Oct 87 10:54:41-CDT ! 365: Posted-Date: Thu, 22 Oct 87 10:55:13 CDT ! 366: Received: from big-d.aca.mcc.com by pp.mcc.com (4.12/KA70822) ! 367: id AA16571; Thu, 22 Oct 87 10:55:19 cdt ! 368: Return-Path: <[email protected]> ! 369: Received: by big-d.aca.mcc.com (3.2/KA70106) ! 370: id AA04247; Thu, 22 Oct 87 10:55:13 CDT ! 371: Date: Thu, 22 Oct 87 10:55:13 CDT ! 372: From: tiemann%[email protected] (Michael Tiemann) ! 373: Message-Id: <[email protected]> ! 374: To: [email protected] ! 375: Subject: expanding file names ! 376: ! 377: *** EOOH *** ! 378: Posted-Date: Thu, 22 Oct 87 10:55:13 CDT ! 379: Return-Path: <[email protected]> ! 380: Date: Thu, 22 Oct 87 10:55:13 CDT ! 381: From: tiemann%[email protected] (Michael Tiemann) ! 382: To: [email protected] ! 383: Subject: expanding file names ! 384: ! 385: When running a program, gdb thoughtfully passes the argument list ! 386: through the shell, expanding files and environment variables as ! 387: needed. It would be nice if the same facility were added to the ! 388: command which adds directories to search paths. For example, it would ! 389: be nice to say "dir ~/foo" . ! 390: ! 391: Michael ! 392: ! 393: ! 394: 1,, ! 395: Received: by xcssun.Berkeley.EDU (5.57/1.25) ! 396: id AA25075; Fri, 23 Oct 87 10:42:52 PDT ! 397: Received: from prep.ai.mit.edu by wheaties.ai.mit.edu; Fri, 23 Oct 87 13:39:37 EDT ! 398: Received: by PREP.AI.MIT.EDU; Fri, 23 Oct 87 13:42:53 EDT ! 399: Received: from relay2.cs.net by RELAY.CS.NET id ac11193; 23 Oct 87 13:03 EDT ! 400: Received: from umb.edu by RELAY.CS.NET id ac05949; 23 Oct 87 13:01 EDT ! 401: Received: by umb.umb.edu; Fri, 23 Oct 87 10:18:40 EDT ! 402: Received: by ileaf.uucp (1.1/SMI-3.0DEV3) ! 403: id AA00599; Wed, 21 Oct 87 10:56:52 EDT ! 404: Received: from marvin.io.uucp by io.uucp (1.1/SMI-3.0DEV3) ! 405: id AA01359; Wed, 21 Oct 87 10:58:45 EDT ! 406: Received: by marvin.io.uucp (3.2/SMI-3.2) ! 407: id AA00334; Wed, 21 Oct 87 11:02:20 EDT ! 408: Date: Wed, 21 Oct 87 11:02:20 EDT ! 409: From: Mark Dionne <io!marvin!md%ileaf.uucp%[email protected]> ! 410: Message-Id: <[email protected]> ! 411: To: [email protected] ! 412: Subject: gdb bug ! 413: ! 414: *** EOOH *** ! 415: Date: Wed, 21 Oct 87 11:02:20 EDT ! 416: From: Mark Dionne <io!marvin!md%ileaf.uucp%[email protected]> ! 417: To: [email protected] ! 418: Subject: gdb bug ! 419: ! 420: The /FMT and @ options of the "print" command seem to interact ! 421: in GDB 2.1. For example: ! 422: ! 423: (gdb) p ($cmpn.buf[-1])@($cmpn.gapb - $cmpn.buf + 1) ! 424: $17 = {-16383, -24285, 55, 27944, -24285, -24285, 55, 28010, -24285, ! 425: -24285, 55, 28076, -24285, -24285, 55, 28142, -24285} ! 426: (gdb) p/x ($cmpn.buf[-1])@($cmpn.gapb - $cmpn.buf + 1) ! 427: $18 = 0xc001 ! 428: ! 429: I guess I see what's happening: the /x is applying to the whole ! 430: array rather than to the individual elements. Feature or bug? ! 431: ! 432: ...!harvard!umb!ileaf!md Mark Dionne, Interleaf ! 433: ...!sun!sunne!ileaf!md Ten Canal Park, Cambridge, MA 02141 ! 434: (617) 577-9813 x5551 ! 435: ! 436: ! 437: ! 438: 1,, ! 439: Received: by PREP.AI.MIT.EDU; Sun, 6 Sep 87 14:27:19 EDT ! 440: Message-Id: <[email protected]> ! 441: Received: from relay2.cs.net by RELAY.CS.NET id af03990; 6 Sep 87 14:22 EDT ! 442: Received: from umb.edu by RELAY.CS.NET id ab03029; 6 Sep 87 14:16 EDT ! 443: Received: by umb.umb.edu; Sun, 6 Sep 87 12:10:34 EDT ! 444: Date: Sun, 6 Sep 87 12:10:34 EDT ! 445: Received: by typo.umb.edu; Sun, 6 Sep 87 12:04:21 EDT ! 446: From: Robert Morris <ram%[email protected]> ! 447: To: [email protected] ! 448: Subject: convenient script ! 449: ! 450: *** EOOH *** ! 451: Date: Sun, 6 Sep 87 12:10:34 EDT ! 452: From: Robert Morris <ram%[email protected]> ! 453: To: [email protected] ! 454: Subject: convenient script ! 455: ! 456: I find it easier to maintain binaries on our heterogenous ! 457: network if I keep this trivial script in gdb source directory. Use it ! 458: if you want. ! 459: ! 460: ! 461: ------------ ! 462: ! 463: #! /bin/csh -f ! 464: # SETUP ! 465: # setup gdb files for presently known machines ! 466: # [email protected] ! 467: # (ram%[email protected] if you have an incomplete mailer) ! 468: # or ...!harvard!umb!ram ! 469: # ! 470: # e.g. SETUP sun3 ! 471: # note that sunX means major release X of sun software, generally ! 472: # sun3 at this writing (gnu 18.41) ! 473: # ! 474: # note GDB with gnuemacs 18.41 is already configured for vaxen ! 475: ! 476: # Bob Morris, UMASS-Boston 9/6/87 ! 477: switch ($1) ! 478: case "sun2": ! 479: ; ! 480: case "sun3" : ! 481: set cputype="m68k"; ! 482: set inittype="suninit"; ! 483: breaksw; ! 484: default : ! 485: set cputype=$1; ! 486: set inittype=$1init; ! 487: breaksw; ! 488: endsw ! 489: echo \#include \"m-$1.h\" > param.h ! 490: echo \#include \"$cputype-pinsn.c\" > pinsn.c ! 491: ed initialize.h <<! >& /dev/null ! 492: /init.h/ ! 493: c ! 494: #include "m-$inittype.h" ! 495: . ! 496: w ! 497: q ! 498: ! ! 499: ! 500: ! 501: ! 502: ! 503: 1,answered,, ! 504: Received: from prep.ai.mit.edu by wheaties.ai.mit.edu; Sat, 19 Dec 87 18:18:50 EST ! 505: Received: by PREP.AI.MIT.EDU; Sat, 19 Dec 87 18:24:38 EST ! 506: Received: from big-d.aca.mcc.com by MCC.COM with TCP; Sat 19 Dec 87 17:19:48-CST ! 507: Date: Sat, 19 Dec 87 17:19:41 CST ! 508: From: [email protected] (Michael Tiemann) ! 509: Posted-Date: Sat, 19 Dec 87 17:19:41 CST ! 510: Message-Id: <[email protected]> ! 511: Received: by big-d.aca.mcc.com (3.2/ACA-V2.1) ! 512: id AA26775; Sat, 19 Dec 87 17:19:41 CST ! 513: To: [email protected] ! 514: Subject: gdb ! 515: ! 516: *** EOOH *** ! 517: Date: Sat, 19 Dec 87 17:19:41 CST ! 518: From: [email protected] (Michael Tiemann) ! 519: Posted-Date: Sat, 19 Dec 87 17:19:41 CST ! 520: To: [email protected] ! 521: Subject: gdb ! 522: ! 523: file values.c, function unpack_field_as_long: ! 524: ! 525: val &= (1 << bitsize) - 1; ! 526: ! 527: This is not as machine independent as it could be. If you feel like ! 528: fixing this potential problem, there are many other instances to worry ! 529: about. ! 530: ! 531: Michael ! 532: ! 533: ! 534: 1,, ! 535: Received: by xcssun.Berkeley.EDU (5.57/1.25) ! 536: id AA04771; Thu, 20 Aug 87 22:33:25 PDT ! 537: Received: from [128.52.22.14] by ucbvax.Berkeley.EDU (5.58/1.27) ! 538: id AA07119; Thu, 20 Aug 87 00:37:04 PDT ! 539: Received: by PREP.AI.MIT.EDU; Thu, 20 Aug 87 03:37:35 EDT ! 540: Date: Thu, 20 Aug 87 03:37:35 EDT ! 541: From: [email protected] (Richard M. Stallman) ! 542: Message-Id: <[email protected]> ! 543: To: [email protected] ! 544: Subject: GDB changes for next version ! 545: ! 546: *** EOOH *** ! 547: Date: Thu, 20 Aug 87 03:37:35 EDT ! 548: From: [email protected] (Richard M. Stallman) ! 549: To: [email protected] ! 550: Subject: GDB changes for next version ! 551: ! 552: 1. Use links, rather than editing some files, to configure it. ! 553: ! 554: 2. Can misc functions eval as their addresses rather than as ! 555: a char in that address? Is this reasonable in all cases ! 556: given that non-functions cannot be distinguished ! 557: and that you might use the result in various ways (arithmetic, etc.). ! 558: ! 559: ! 560: 1,, ! 561: Received: by xcssun.Berkeley.EDU (5.57/1.25) ! 562: id AA09136; Sat, 29 Aug 87 02:20:15 PDT ! 563: Received: from PREP.AI.MIT.EDU by ucbvax.Berkeley.EDU (5.58/1.27) ! 564: id AA26072; Sat, 29 Aug 87 02:21:51 PDT ! 565: Received: by PREP.AI.MIT.EDU; Sat, 29 Aug 87 05:22:30 EDT ! 566: Received: by RUTGERS.EDU (5.54/1.14) with UUCP ! 567: id AA22247; Sat, 29 Aug 87 05:21:13 EDT ! 568: Received: from sequent.UUCP by spool.wisc.edu; Sat, 29 Aug 87 04:18:41 CDT ! 569: Received: from reed.UUCP by ogcvax.OGC.EDU (5.51/OGC_4.8) ! 570: id AA08044; Fri, 28 Aug 87 20:06:41 PDT ! 571: Received: by reed.UUCP (5.51/5.17) ! 572: id AA05059; Fri, 28 Aug 87 19:19:15 PDT ! 573: From: [email protected] (Keith Packard) ! 574: Message-Id: <[email protected]> ! 575: To: [email protected] ! 576: Subject: Re: GDB ! 577: In-Reply-To: Your message of Thu, 20 Aug 87 03:39:37 EDT. ! 578: <[email protected]> ! 579: Date: Fri, 28 Aug 87 19:19:13 PDT ! 580: ! 581: *** EOOH *** ! 582: From: [email protected] (Keith Packard) ! 583: To: [email protected] ! 584: Subject: Re: GDB ! 585: In-Reply-To: Your message of Thu, 20 Aug 87 03:39:37 EDT. ! 586: <[email protected]> ! 587: Date: Fri, 28 Aug 87 19:19:13 PDT ! 588: ! 589: ! 590: Here is a simple test program for exibiting the trouble with signals: ! 591: ! 592: ----- ! 593: # include <signal.h> ! 594: ! 595: main () ! 596: { ! 597: int handle (); ! 598: int i; ! 599: signal (SIGALRM, handle); ! 600: alarm (5); ! 601: for (i = 0; i < 100000; i++) ! 602: printf ("%d\n", i); ! 603: } ! 604: ! 605: handle () ! 606: { ! 607: printf ("signal!\n"); ! 608: alarm (5); ! 609: } ! 610: ----- ! 611: ! 612: To demonstrate the problem, simply place a breakpoint before the call to ! 613: alarm and then start stepping through the program: ! 614: ! 615: (gdb) break 7 ! 616: (gdb) step ! 617: ... ! 618: ... ! 619: ! 620: Eventually, the alarm call occurs and the program ends up in some ! 621: signal handling code -- unfortuantely a machine dependent location. At this ! 622: point, because the fp has moved out of the current function (in fact on ! 623: many machines the frame is not in a consistent state at this point) gdb ! 624: assumes that a new function has started and suspends execution with another ! 625: prompt. ! 626: ! 627: A reasonable solution would be to have gdb insert a breakpoint at the ! 628: expected signal return address and continue to that breakpoint -- I've ! 629: implemented this and found that it works. There is, however, one nasty ! 630: problem -- longjmp around the suspended frame and the breakpoint is not hit ! 631: at the expected time. ! 632: ! 633: Have fun... ! 634: ! 635: keith packard ! 636: ! 637: tektronix!reed!keith ! 638: ! 639: ! 640: 1,, ! 641: Received: by xcssun.Berkeley.EDU (5.57/1.25) ! 642: id AA09143; Sat, 29 Aug 87 02:24:58 PDT ! 643: Received: by neptune.Berkeley.EDU (5.57/1.25) ! 644: id AA03738; Sat, 29 Aug 87 02:24:50 PDT ! 645: Date: Sat, 29 Aug 87 02:24:50 PDT ! 646: From: [email protected] (Richard Stallman) ! 647: Message-Id: <[email protected]> ! 648: To: [email protected] ! 649: Subject: GDB bug ! 650: Reply-To: [email protected] ! 651: ! 652: *** EOOH *** ! 653: Date: Sat, 29 Aug 87 02:24:50 PDT ! 654: From: [email protected] (Richard Stallman) ! 655: To: [email protected] ! 656: Subject: GDB bug ! 657: Reply-To: [email protected] ! 658: ! 659: Is there any way to make GDB, when stepping across a function call, ! 660: notice any attempt to longjump out of that call? ! 661: Perhaps an implicit breakpoint at longjump. ! 662: If longjump is called, find the pc in the jmp_buf and put ! 663: a self-deleting breakpoint there. ! 664: ! 665: ! 666: 1,, ! 667: Received: by xcssun.Berkeley.EDU (5.57/1.25) ! 668: id AA07976; Fri, 28 Aug 87 09:26:12 PDT ! 669: Received: from PREP.AI.MIT.EDU by ucbvax.Berkeley.EDU (5.58/1.27) ! 670: id AA03230; Fri, 28 Aug 87 09:28:04 PDT ! 671: Received: by PREP.AI.MIT.EDU; Fri, 28 Aug 87 12:28:43 EDT ! 672: Date: Fri, 28 Aug 87 12:28:43 EDT ! 673: From: [email protected] (Paul Rubin) ! 674: Message-Id: <[email protected]> ! 675: To: [email protected] ! 676: Subject: gdb suggestions ! 677: ! 678: *** EOOH *** ! 679: Date: Fri, 28 Aug 87 12:28:43 EDT ! 680: From: [email protected] (Paul Rubin) ! 681: To: [email protected] ! 682: Subject: gdb suggestions ! 683: ! 684: 1. I wish gdb had a command to re-read the sources so that I can edit ! 685: the program and recompile it without having to kill and restart gdb. ! 686: ! 687: 2. Would be nice if gdb could somehow connect the subprocess's tty channels ! 688: to a pty, so I can run gdb in an X window and the subprocess in a different ! 689: (xterm) window. ! 690: ! 691: This might need hair to detect if the subprocess is running when you try ! 692: to examine variables, etc. and stop the subproc or report an error if it is. ! 693: ! 694: ! 695: 1,, ! 696: Received: from prep.ai.mit.edu by wheaties.ai.mit.edu; Mon, 4 Apr 88 12:43:31 EDT ! 697: Received: from CCA.CCA.COM by prep.ai.mit.edu; Mon, 4 Apr 88 11:30:55 EST ! 698: Received: by CCA.CCA.COM; Mon, 4 Apr 88 12:42:16 EDT ! 699: Date: Mon, 4 Apr 88 12:42:16 EDT ! 700: From: [email protected] (Alexis Layton) ! 701: Message-Id: <[email protected]> ! 702: To: [email protected] ! 703: Subject: Wish List for GDB ! 704: Cc: [email protected] ! 705: ! 706: *** EOOH *** ! 707: Date: Mon, 4 Apr 88 12:42:16 EDT ! 708: From: [email protected] (Alexis Layton) ! 709: To: [email protected] ! 710: Subject: Wish List for GDB ! 711: Cc: [email protected] ! 712: ! 713: GDB is a good debugger. I like it. I think it is lacking in functionality ! 714: in the following areas: ! 715: ! 716: 1. "Finish this loop" capability. If I am stepping through code and ! 717: encounter a for-, do-, or while-loop, after a few iterations I generally ! 718: get bored. I want to be able to say "finish this loop"; i.e. continue ! 719: until the next statement after the loop is executed. Note this is ! 720: complicated by gotos and nested loops. ! 721: ! 722: 2. GDB only prints the last line of a multi-line statement which has been ! 723: continued. Since this is often of the form ! 724: ! 725: foobar)); ! 726: ! 727: it is not very convenient. When stepping through a file using next (or step), ! 728: ALL non-blank text lines (excepting perhaps close-braces?) between the last ! 729: displayed line and the current one should be displayed. ! 730: ! 731: 3. If there is a way to call a function interactively, I couldn't find it ! 732: in the on-line help. (Having neither GNU Emacs or TeX, reading the .texinfo ! 733: files is a bit tedious.) ! 734: ! 735: 4. On occasion, when debugging a function with deeply nested code in a loop, ! 736: I want to have "hierarchical" breakpoints -- that is, I want certain ! 737: breakpoints automatically enabled if a certain breakpoint is triggered, ! 738: but not if it hasn't. I haven't thought of a good design for this yet. ! 739: ! 740: 5. tbreak is not temporary enough; It should delete the breakpoint, not ! 741: disable it. ! 742: ! 743: 6. what about "next to linenumber", or "continue to linenumber" -- the ! 744: only difference being next single-steps and continue sets an ephemeral ! 745: breakpoint and then deletes it. This would also make debugging large ! 746: functions easier. ! 747: ! 748: 7. variable access breakpoints (break when variable changes value) ! 749: ! 750: 8. should be able to use "set" to change initialization values before ! 751: "run" is issued. Makes setting of static debugging control variables ! 752: easier. Right now I have to break main all the time. ! 753: ! 754: 9. GDB seems to be slow in reading/processing the symbol table -- can ! 755: this be improved? ! 756: ! 757: 10. Preprocessor support. Is there any way to run the command input through ! 758: the preprocessor or otherwise get a handle on defines? Particlarly in ! 759: debugging things like ncurses, which use umpteen defines. ! 760: ! 761: (E.g., "delete_line" is defined as SP->_StrCaps[28] or some such nonsense.) ! 762: ! 763: Perhaps you could spawn off a CPP and then pipe the command input to it, ! 764: appropriately down-loading the included files and whatever # text was in ! 765: the C file being debugged.... ! 766: ! 767: Most of these comments of course apply to GDB+ as well. ! 768: ! 769: Well, that's just a few of my thoughts. Hope they give you some ideas. ! 770: ! 771: Alexis Layton ! 772: [email protected] ! 773: ! 774: ! 775: 1,, ! 776: Summary-line: 27-Nov steve%[email protected] #gdb ! 777: Received: from prep.ai.mit.edu by wheaties.ai.mit.edu; Wed, 2 Dec 87 16:58:16 EST ! 778: Received: by PREP.AI.MIT.EDU; Wed, 2 Dec 87 17:00:22 EST ! 779: Message-Id: <[email protected]> ! 780: Received: from relay2.cs.net by RELAY.CS.NET id ag03066; 2 Dec 87 16:06 EST ! 781: Received: from next.com by RELAY.CS.NET id ae26721; 2 Dec 87 16:00 EST ! 782: Received: from indiana.next.com by next.next.com (3.2/SMI-3.0DEV3) ! 783: id AA08711; Fri, 27 Nov 87 10:47:36 PST ! 784: Date: Fri, 27 Nov 87 10:41:41 PST ! 785: From: steve%[email protected] ! 786: To: [email protected] ! 787: Subject: gdb ! 788: ! 789: *** EOOH *** ! 790: Date: Fri, 27 Nov 87 10:41:41 PST ! 791: From: steve%[email protected] ! 792: To: [email protected] ! 793: Subject: gdb ! 794: ! 795: I copied it into wheaties:gdb.tar.next.Z. The following is our "TODO" list. ! 796: An asterisk notes an entry is completed. ! 797: ! 798: - objc features: ! 799: * printing objects: ! 800: - printing indexed instance variables. ! 801: * implement object-print command which lists ! 802: class, methods, source file, etc. ! 803: * info objects command which lists all objects. ! 804: ! 805: * message expression evaluation: ! 806: * Use symbolic method name/object name. ! 807: - Add varargs support. ! 808: - printing instance variables: ! 809: - When all else fails, attempt to lookup an unknown ! 810: local as an instance variable (if currently in a ! 811: method handler/.m file). ! 812: * breakpoints: ! 813: - set breakpoints in object/method handler. ! 814: * stepping: ! 815: - stepm command that steps over _msg call into the ! 816: message handler when source is available. ! 817: * printing methods: ! 818: * info method that lists objects that implement a given ! 819: method. ! 820: * list command: ! 821: - modifiy it so that you can list the source for a given ! 822: object/method pair. ! 823: - backtrace: ! 824: - fix braindamaged backtrace (_msg doesn't maintain a6 linkage). ! 825: - poseAs: ! 826: - Reinitialize Obj-C-Data when poseAs is used. ! 827: - tenex: ! 828: * Finish incremental history searches. ! 829: * Add history search/reverse search. ! 830: * Add \e< and \e> ! 831: - Save macros on exit. ! 832: - Add commands to reset/append/prepend macrofiles. ! 833: - Add ability to read macrofiles once in emacs mode. ! 834: - print bindings command. ! 835: - command completion: ! 836: - gdb commands? ! 837: - symbol table entries? ! 838: - symbol tables: ! 839: - Modify current .sym file information to be left in .o files and ! 840: relocated by the debugger at load time. ! 841: - Load .sym file info on demand. ! 842: - documentation: ! 843: - mach port: ! 844: - use shared memory. ! 845: - multiple threads. ! 846: - multiple tasks. ! 847: - /dev/proc???? ! 848: - debug an already running task. ! 849: - debug a program with minimal symbol information. ! 850: - debugger support for shared libraries. ! 851: - misc: ! 852: - watchpoints. ! 853: - add a way to set evaluation scope/context to a file. ! 854: - disassembly enhancement: ! 855: - support symbolic names for locals and registers and ! 856: args. ! 857: - macro args (for user commands). ! 858: - case insensitivity for searches (info command/list searches). ! 859: - by default, load symbol table with exec-file. ! 860: - clean up structure printing. ! 861: - assmebler source level debugging. ! 862: - CPP info in the debugger (be able to get to #defines). ! 863: - gdbtool: ! 864: Source windows: ! 865: menus: ! 866: - tag support (callee/caller ala dir). ! 867: - break on line. ! 868: - unbreak on line. ! 869: - set one shot breakpoint. ! 870: - continue until line (with/without enabling other breakpoints). ! 871: - search forward/reverse. ! 872: - yank text for command window. ! 873: attributes: ! 874: - dir-like interface where each stack frame has a window. ! 875: Windows can be closed and are re-created when that stack frame ! 876: is reached again. If windows are too slow, beat up Leo. ! 877: - source windows have line-numbers/breakpoint indicator/last ! 878: PC in that window/current PC. ! 879: - full dir-like tags support for bringing up new windows (not on ! 880: the execution stack). ! 881: - Allow editing of source in a window (gray-scale for new lines/ ! 882: deleted lines) so that current debugging session still works. ??? ! 883: - incremental compiles (dream on!). ! 884: Data display windows: ! 885: - auto display window. ! 886: - graphic structure display. ! 887: Stack display window: ! 888: - stack trace display. Menu buttons: ! 889: - up/down. ! 890: - continue until stack level. ! 891: Command window: ! 892: menu: ! 893: - evaluate selected expression. ! 894: attributes: ! 895: - Remote debugging: ! 896: - Add other protocols (ethernet?, shared memory). ! 897: - C Interpreter. ! 898: - Control flow. ! 899: - Interpret changed code. ! 900: - Add subroutines. ! 901: ! 902: ! 903: ! 904: 1,, ! 905: Summary-line: 22-Oct tiemann%[email protected] #expanding file names ! 906: Received: by xcssun.Berkeley.EDU (5.57/1.25) ! 907: id AA22869; Thu, 22 Oct 87 09:50:30 PDT ! 908: Received: from prep.ai.mit.edu by wheaties.ai.mit.edu; Thu, 22 Oct 87 12:17:59 EDT ! 909: Received: by PREP.AI.MIT.EDU; Thu, 22 Oct 87 12:21:00 EDT ! 910: Received: from pp.mcc.com by MCC.COM with TCP; Thu 22 Oct 87 10:54:41-CDT ! 911: Posted-Date: Thu, 22 Oct 87 10:55:13 CDT ! 912: Received: from big-d.aca.mcc.com by pp.mcc.com (4.12/KA70822) ! 913: id AA16571; Thu, 22 Oct 87 10:55:19 cdt ! 914: Return-Path: <[email protected]> ! 915: Received: by big-d.aca.mcc.com (3.2/KA70106) ! 916: id AA04247; Thu, 22 Oct 87 10:55:13 CDT ! 917: Date: Thu, 22 Oct 87 10:55:13 CDT ! 918: From: tiemann%[email protected] (Michael Tiemann) ! 919: Message-Id: <[email protected]> ! 920: To: [email protected] ! 921: Subject: expanding file names ! 922: ! 923: *** EOOH *** ! 924: Posted-Date: Thu, 22 Oct 87 10:55:13 CDT ! 925: Return-Path: <[email protected]> ! 926: Date: Thu, 22 Oct 87 10:55:13 CDT ! 927: From: tiemann%[email protected] (Michael Tiemann) ! 928: To: [email protected] ! 929: Subject: expanding file names ! 930: ! 931: When running a program, gdb thoughtfully passes the argument list ! 932: through the shell, expanding files and environment variables as ! 933: needed. It would be nice if the same facility were added to the ! 934: command which adds directories to search paths. For example, it would ! 935: be nice to say "dir ~/foo" . ! 936: ! 937: Michael ! 938: ! 939: ! 940: 1, edited, answered,, ! 941: Received: by xcssun.Berkeley.EDU (5.57/1.25) ! 942: id AA26610; Wed, 2 Mar 88 05:27:51 PST ! 943: Received: from prep.ai.mit.edu by wheaties.ai.mit.edu; Wed, 2 Mar 88 08:26:23 EST ! 944: Received: from cgl.ucsf.EDU by prep.ai.mit.edu; Wed, 2 Mar 88 08:25:58 EST ! 945: Received: by cgl.ucsf.edu (5.54/GSC4.5) ! 946: id AA27646; Wed, 2 Mar 88 05:23:57 PST ! 947: Received: by hop.toad.com id AA00787; Wed, 2 Mar 88 05:22:55 PST ! 948: Date: Wed, 2 Mar 88 05:22:55 PST ! 949: From: [email protected] (John Gilmore) ! 950: Message-Id: <[email protected]> ! 951: To: [email protected] ! 952: Subject: A few things Sun dbx does that gdb doesn't... ! 953: ! 954: *** EOOH *** ! 955: Date: Wed, 2 Mar 88 05:22:55 PST ! 956: From: [email protected] (John Gilmore) ! 957: To: [email protected] ! 958: Subject: A few things Sun dbx does that gdb doesn't... ! 959: ! 960: * gdb won't reread the executable's symbol table when its mod time ! 961: has changed. The user has to explicitly reread it after recompiling ! 962: the software and before typing "run". ! 963: ! 964: * gdb has no command to report the current argv for "run" commands. ! 965: "info program" or "info environment" should display this info. (dbx ! 966: doesn't do this either, but I noticed it at the same time.) ! 967: ! 968: ! 969: 1, answered,, ! 970: Received: by xcssun.Berkeley.EDU (5.57/1.25) ! 971: id AA14587; Tue, 16 Feb 88 16:19:12 PST ! 972: Received: from prep.ai.mit.edu by wheaties.ai.mit.edu; Tue, 16 Feb 88 19:17:21 EST ! 973: Received: from UNIX.SRI.COM by prep.ai.mit.edu; Tue, 16 Feb 88 19:08:02 EST ! 974: Received: by sri-unix.ARPA (5.31/5.14) ! 975: id AA25586; Tue, 16 Feb 88 16:12:32 PST ! 976: From: [email protected] ! 977: Received: from ozona.orc.olivetti.com by orc.uucp (3.2/SMI-3.2) ! 978: id AA01567; Tue, 16 Feb 88 16:01:02 PST ! 979: Received: from localhost by ozona.orc.olivetti.com (3.2/SMI-3.2) ! 980: id AA08259; Tue, 16 Feb 88 16:02:22 PST ! 981: Message-Id: <[email protected]> ! 982: To: [email protected] ! 983: Subject: GDB suggestion ! 984: Reply-To: chase%[email protected] ! 985: Date: Tue, 16 Feb 88 16:02:18 -0800 ! 986: ! 987: *** EOOH *** ! 988: From: [email protected] ! 989: To: [email protected] ! 990: Subject: GDB suggestion ! 991: Reply-To: chase%[email protected] ! 992: Date: Tue, 16 Feb 88 16:02:18 -0800 ! 993: ! 994: ! 995: Today I found myself wanting a feature in a debugger that neither GDB ! 996: nor DBX supports. I checked the GDB documentation and could not find ! 997: it there. This may be too Unix-specific, so you may not want to add ! 998: it. It may also not be of general use. Nevertheless, I will suggest ! 999: it; it's certainly easy to ignore the suggestion. ! 1000: ! 1001: What I wanted to do was limit the datasize of a program that I was ! 1002: debugging (I am debugging someone else's garbage collector, lucky ! 1003: me) without also imposing that limit on the debugger. I didn't see ! 1004: any mention of such a command in either debugger's documentation. ! 1005: ! 1006: In other news, the alleged (ansi) C and Modula library is beginning to ! 1007: work. (The garbage collector is part of the Modula-2+ half.) ! 1008: ! 1009: David Chase ! 1010: Olivetti Research Center, Menlo Park ! 1011: ! 1012: ! 1013: 1,, ! 1014: Return-Path: <[email protected]> ! 1015: Received: by frosted-flakes.ai.mit.edu; Sat, 30 Apr 88 17:05:42 EDT ! 1016: Date: Sat, 30 Apr 88 17:05:42 EDT ! 1017: From: [email protected] (Richard Stallman) ! 1018: Message-Id: <[email protected]> ! 1019: To: rms ! 1020: Subject: GDB idea ! 1021: ! 1022: *** EOOH *** ! 1023: Return-Path: <[email protected]> ! 1024: Date: Sat, 30 Apr 88 17:05:42 EDT ! 1025: From: [email protected] (Richard Stallman) ! 1026: To: rms ! 1027: Subject: GDB idea ! 1028: ! 1029: Expressions should record the block that symbols were looked up in, ! 1030: if the symbols proved not to be static, ! 1031: and an auto-display should be disabled automatically when it is ! 1032: not in the block where the results would be meaningful. ! 1033: ! 1034: ! 1035: 1,, ! 1036: Received: from ai.ai.mit.edu by wheaties.ai.mit.edu; Sun, 8 May 88 12:52:31 EDT ! 1037: Received: from prep.ai.mit.edu (TCP 20015020016) by AI.AI.MIT.EDU 8 May 88 05:38:21 EDT ! 1038: Received: from lilac.Berkeley.EDU by prep.ai.mit.edu; Sun, 8 May 88 04:12:02 EST ! 1039: Received: from web5h.berkeley.edu ! 1040: by lilac.berkeley.edu (5.54 (CFC 4.22.3)/1.16.18) ! 1041: id AA27424; Sun, 8 May 88 02:33:06 PDT ! 1042: Received: by web5h.berkeley.edu (3.2/SMI-3.0DEV3.8MXl) ! 1043: id AA05599; Sun, 8 May 88 02:33:41 PDT ! 1044: Date: Sun, 8 May 88 02:33:41 PDT ! 1045: From: phr%[email protected] ! 1046: Message-Id: <[email protected]> ! 1047: To: [email protected] ! 1048: Subject: suggestion (gdb 2.4): print function names ! 1049: ! 1050: *** EOOH *** ! 1051: Date: Sun, 8 May 88 02:33:41 PDT ! 1052: From: phr%[email protected] ! 1053: To: [email protected] ! 1054: Subject: suggestion (gdb 2.4): print function names ! 1055: ! 1056: If p is a pointer to function, "print p" should print the name ! 1057: of the function that p points to, as well as the numeric value. ! 1058: Dbx does this. ! 1059: ! 1060: ! 1061: ! 1062: 1,, ! 1063: Received: from lilac.berkeley.edu by wheaties.ai.mit.edu; Wed, 11 May 88 23:14:39 EDT ! 1064: Received: from web8e.berkeley.edu ! 1065: by lilac.berkeley.edu (5.54 (CFC 4.22.3)/1.16.18) ! 1066: id AA11864; Wed, 11 May 88 20:11:12 PDT ! 1067: Received: by web8e.berkeley.edu (3.2/SMI-3.0DEV3.8MXl) ! 1068: id AA06549; Wed, 11 May 88 20:11:44 PDT ! 1069: Date: Wed, 11 May 88 20:11:44 PDT ! 1070: From: phr%[email protected] ! 1071: Message-Id: <[email protected]> ! 1072: To: [email protected] ! 1073: Subject: gdb suggestion ! 1074: ! 1075: *** EOOH *** ! 1076: Date: Wed, 11 May 88 20:11:44 PDT ! 1077: From: phr%[email protected] ! 1078: To: [email protected] ! 1079: Subject: gdb suggestion ! 1080: ! 1081: If the process signal mask of a program is saved in the core dump, ! 1082: then gdb should have a way to read it. I have an xemacs that hangs ! 1083: in a blocking read from XCreateWindow when I run it from the csh, ! 1084: but works fine when run under gdb. (Does this mean a gdb bug?). ! 1085: ! 1086: ! 1087: 1, answered,, ! 1088: Return-Path: <[email protected]> ! 1089: Received: by sugar-smacks.ai.mit.edu; Tue, 24 May 88 00:34:01 EDT ! 1090: Date: Tue, 24 May 88 00:34:01 EDT ! 1091: From: [email protected] (Thomas M. Breuel) ! 1092: Message-Id: <[email protected]> ! 1093: To: rms ! 1094: Subject: problem with gdb... ! 1095: ! 1096: *** EOOH *** ! 1097: Return-Path: <[email protected]> ! 1098: Date: Tue, 24 May 88 00:34:01 EDT ! 1099: From: [email protected] (Thomas M. Breuel) ! 1100: To: rms ! 1101: Subject: problem with gdb... ! 1102: ! 1103: When tracing a program that forks, the breakpoints aren't removed in the ! 1104: child and it dies with a trace/bpt trap. Isn't there a more proper way to ! 1105: handle this? ! 1106: ! 1107: Thomas. ! 1108: ! 1109: ! 1110: 1, forwarded, answered,, ! 1111: Received: from ATHENA (ATHENA.MIT.EDU) by wheaties.ai.mit.edu; Sat, 25 Jun 88 04:02:57 EDT ! 1112: From: [email protected] ! 1113: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA21892; Sat, 25 Jun 88 04:00:11 EDT ! 1114: Received: by BRIDGETOWN.MIT.EDU (5.45/4.7) id AA13640; Sat, 25 Jun 88 03:59:57 EDT ! 1115: Date: Sat, 25 Jun 88 03:59:57 EDT ! 1116: Message-Id: <[email protected]> ! 1117: To: [email protected] ! 1118: Subject: gdb suggestion ! 1119: ! 1120: *** EOOH *** ! 1121: From: [email protected] ! 1122: Date: Sat, 25 Jun 88 03:59:57 EDT ! 1123: To: [email protected] ! 1124: Subject: gdb suggestion ! 1125: ! 1126: Debugging X toolkit stuff involves looking at structures that fill up ! 1127: several screens. GDB would be a lot easier to use if it supported ! 1128: some sort of pretty-printing of these structures. ! 1129: ! 1130: Jeff ! 1131: ! 1132: ! 1133: 1, forwarded,, ! 1134: Received: from prep.ai.mit.edu by wheaties.ai.mit.edu; Thu, 23 Jun 88 04:32:12 EDT ! 1135: Received: from ic.Berkeley.EDU by prep.ai.mit.edu; Thu, 23 Jun 88 03:19:27 EST ! 1136: Received: by ic.berkeley.edu (5.57/1.28) ! 1137: id AA02077; Thu, 23 Jun 88 01:28:08 PDT ! 1138: Date: Thu, 23 Jun 88 01:28:08 PDT ! 1139: From: [email protected] (Wayne A. Christopher) ! 1140: Message-Id: <[email protected]> ! 1141: To: [email protected] ! 1142: Subject: gdb request ! 1143: ! 1144: *** EOOH *** ! 1145: Date: Thu, 23 Jun 88 01:28:08 PDT ! 1146: From: [email protected] (Wayne A. Christopher) ! 1147: To: [email protected] ! 1148: Subject: gdb request ! 1149: ! 1150: One suggestion for future versions of gdb -- the trace command of dbx is very ! 1151: useful, and a lot easier to use than the "commands" feature in gdb. Although ! 1152: it's not necessary, it would be nice to have it. ! 1153: ! 1154: Wayne ! 1155: ! 1156: ! 1157: 1, forwarded,, ! 1158: Return-Path: <[email protected]> ! 1159: Received: from prep.ai.mit.edu by life.ai.mit.edu; Sun, 24 Jul 88 03:40:33 EDT ! 1160: Received: from scruff.Berkeley.EDU by prep.ai.mit.edu; Sun, 24 Jul 88 02:17:27 EST ! 1161: Received: by scruff.berkeley.edu (5.57/1.28) ! 1162: id AA19389; Sun, 24 Jul 88 00:35:41 PDT ! 1163: Date: Sun, 24 Jul 88 00:35:41 PDT ! 1164: From: [email protected] (Wayne A. Christopher) ! 1165: Message-Id: <[email protected]> ! 1166: To: [email protected] ! 1167: Subject: gdb feature ! 1168: ! 1169: *** EOOH *** ! 1170: Return-Path: <[email protected]> ! 1171: Date: Sun, 24 Jul 88 00:35:41 PDT ! 1172: From: [email protected] (Wayne A. Christopher) ! 1173: To: [email protected] ! 1174: Subject: gdb feature ! 1175: ! 1176: It would be nice if I could stop and background a process running under ! 1177: gdb. Now gdb lets the process get the ^Z and gives me a prompt, instead ! 1178: of stopping also. ! 1179: ! 1180: Wayne ! 1181: ! 1182: ! 1183: 1,, ! 1184: Return-Path: <[email protected]> ! 1185: Received: from prep.ai.mit.edu by life.ai.mit.edu; Tue, 30 Aug 88 23:18:51 EDT ! 1186: Received: from ATHENA.MIT.EDU by prep.ai.mit.edu; Tue, 30 Aug 88 21:44:58 EST ! 1187: Received: by ATHENA.MIT.EDU (5.45/4.7) id AA29972; Tue, 30 Aug 88 23:16:03 EDT ! 1188: Received: by E40-342A-3 (5.45/4.7) ! 1189: id AA10004; Tue, 30 Aug 88 23:15:58 EDT ! 1190: Date: Tue, 30 Aug 88 23:15:58 EDT ! 1191: From: Bill Sommerfeld <[email protected]> ! 1192: Message-Id: <8808310315.AA10004@E40-342A-3> ! 1193: To: [email protected] ! 1194: Subject: SET_STACK_LIMIT_HUGE. ! 1195: ! 1196: *** EOOH *** ! 1197: Return-Path: <[email protected]> ! 1198: Date: Tue, 30 Aug 88 23:15:58 EDT ! 1199: From: Bill Sommerfeld <[email protected]> ! 1200: To: [email protected] ! 1201: Subject: SET_STACK_LIMIT_HUGE. ! 1202: ! 1203: I just had the pleasure of figuring out why a program which worked ! 1204: under GDB failed (with a segv) when run under the shell. It turns out ! 1205: that it was allocating too much space in the stack, and dying with a ! 1206: segmentation violation when it overran the stack. ! 1207: ! 1208: I note that gdb/main.c unlimits the stack, presumably to allow gdb to ! 1209: use alloca to its heart's content. This is well and good, but in the ! 1210: interests of making the execution and debugging environments ! 1211: functionally identical, could it at least set the limit back down to ! 1212: what it used to be when it starts the child process? ! 1213: ! 1214: - Bill ! 1215: ! 1216: ! 1217: 1, answered,, ! 1218: Return-Path: <[email protected]> ! 1219: Received: from hobbes.ai.mit.edu by wheaties.ai.mit.edu; Thu, 1 Sep 88 23:13:03 EDT ! 1220: Received: from localhost.ARPA by hobbes.ai.mit.edu; Thu, 1 Sep 88 23:08:41 est ! 1221: Message-Id: <[email protected]> ! 1222: To: [email protected] (Richard Stallman) ! 1223: Cc: [email protected] ! 1224: Subject: Re: GDB work that needs to be done ! 1225: In-Reply-To: Your message of Thu, 01 Sep 88 19:23:47 -0400. ! 1226: <[email protected]> ! 1227: Date: Thu, 01 Sep 88 23:08:39 +0900 ! 1228: From: [email protected] ! 1229: ! 1230: *** EOOH *** ! 1231: Return-Path: <[email protected]> ! 1232: To: [email protected] (Richard Stallman) ! 1233: Cc: [email protected] ! 1234: Subject: Re: GDB work that needs to be done ! 1235: In-Reply-To: Your message of Thu, 01 Sep 88 19:23:47 -0400. ! 1236: <[email protected]> ! 1237: Date: Thu, 01 Sep 88 23:08:39 +0900 ! 1238: From: [email protected] ! 1239: ! 1240: ! 1241: Also: ! 1242: ! 1243: 5. Step until past current line or out of stack frame. ! 1244: ! 1245: ! 1246: 1,, ! 1247: Return-Path: <[email protected]> ! 1248: Received: by sugar-bombs.ai.mit.edu; Fri, 2 Sep 88 12:43:28 EDT ! 1249: Date: Fri, 2 Sep 88 12:43:28 EDT ! 1250: From: [email protected] (Richard Stallman) ! 1251: Message-Id: <[email protected]> ! 1252: To: [email protected] ! 1253: Cc: rms ! 1254: In-Reply-To: [email protected]'s message of Thu, 01 Sep 88 23:08:39 +0900 <[email protected]> ! 1255: Subject: GDB work that needs to be done ! 1256: ! 1257: *** EOOH *** ! 1258: Return-Path: <[email protected]> ! 1259: Date: Fri, 2 Sep 88 12:43:28 EDT ! 1260: From: [email protected] (Richard Stallman) ! 1261: To: [email protected] ! 1262: Cc: rms ! 1263: In-Reply-To: [email protected]'s message of Thu, 01 Sep 88 23:08:39 +0900 <[email protected]> ! 1264: Subject: GDB work that needs to be done ! 1265: ! 1266: Step until past current line or out of stack frame. ! 1267: ! 1268: I think this should be a command called `until': ! 1269: ! 1270: until LINE run until line LINE. ! 1271: until run until reach the following line. ! 1272: ! 1273: It can work by setting a temporary (delete when hit) breakpoint ! 1274: at the specified destination and then doing `finish'. ! 1275: ! 1276: ! 1277:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.