![[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.