gnu1987/gdb/gdb.ideas

Date: Wed, 24 Sep 86 16:33:11 EDT
From: mly (Richard Mlynarik)
To: rms
Cc: mly-prep
Subject: gdb gripes/suggestions/requests

If would be really nice to have some way to do conditionals in user
  commands -- though this is really stretching the functionality of
  gdb a little too much, perhaps.  (see ~mly/e/.gdbint for some of
  the contortions I go through with || to get conditional
  evaluation...)

The names of all the breakpoint-hacking functions are very
  confusing.  Perhaps they should all be subcommands of the "break"
  command.  (For example, it isn't obvious at all that "commands"
  has anthing to do with breakpoints)  "br" could be defined as a 
  synonym for "breakpoint set" or "set breakpoint" or whatever.

A -real- win wuold be some way to execute until he next function-call
  (like c-d in the cadr debugger)  This would even be useful if it
  were rather slow -- it would probably be faster than setting
  temporary breakpoints in all the functions which might be called,
  and would certainly be faster than "step"ping one's way until a
  funcall happened.

"info source" should mention what the directory search-path is (ie
  what "info dir" says) and in which directory it found each of the
  source files (and which source files it cannot locate in the
  search-path)


From: mly@MICHAEL.AI.MIT.EDU (Richard Mlynarik)
To: rms@prep.ai.mit.edu
Subject: gdb suggestions (from hpux cdb)
Reply-To: mly-prep@prep.ai.mit.edu

"find-bug" command says "I can see the problem, but it will do you
good to find it yourself"

The gdb manual should explicitly state that gdb has no control over
forked (or execed or whatever) subprocesses.

I'd still like it if "delete" said what it had done.


Date: Tuesday, 13 May 1986, 00:40-EDT
From: <rms@LMI-ANGEL>
Sender: JC@LMI-ANGEL
Subject: interesting sdb features
To: rms@angel

output format p = pointer to procedure.

foo/x or foo/4x uses size of foo as size to print.

foo[1;4] to get elements 1 thru 4.

Continue to specified line number.

Interactively delete all breakpoints (asking about each one).



Command to write backtrace into a file, or even better to duplicate all
output to a file.  This could work by playing with descriptor 1,
making it a pipe to `tee'.  The original descriptor 1 is saved and
this mode can be turned off by putting it back.
  Date: Wed, 18 Feb 87 15:37:14 EST
  From: rms (Richard M. Stallman)
  Message-Id: <8702182037.AA16492@prep.ai.mit.edu>
  To: mly-prep@prep.ai.mit.edu
  In-Reply-To: <8702181913.AA16118@prep.ai.mit.edu>
  Subject: gdb "photo" command

  I don't think all this is worth the trouble to do now,
  because the right way to do it on TRIX is totally different
  and much easier.


Commands to enable and disable the autodisplays.  Associate
autodisplays with breakpoints perhaps, so they only display
at those breakpoints; this is easier than using breakpoint commands.

Remember how each breakpoint's position was specified.
Have command to reread symbol table and respecify each
breakpoint using same args (line number or function name) as before.

Have way to proceed process in background so that can then suspend
gdb but have subprocess continue