Re: GDB needs a --cmdline option

[Tom Tromey <tromey@cygnus.com>]

>>>>> "Mo" == Mo DeJong <mdejong@cygnus.com> writes:

Mo> I have been running into a problem with gdb that it seems would be
Mo> nicely solved with a new command line option --cmdline.

Mo> Now if there is a problem with the gcj executable, I would want to
Mo> use gdb to debug it. The problem is I want to debug it in the
Mo> context of the Makefile run, not just by itself on the command
Mo> line.

Mo> gdb gcj --cmdline "-C *.java gnu/gcj/convert/*.java gnu/gcj/*.java"

I agree that something like this is needed.  But I am not that fond of
this incarnation.  I particularly don't like the quoting on the
command line above.

I'd like to see gdb have two additional modes: `invisible' mode, and
the one you suggest.  You would activate it something like this:

  gdb --invisible -- gcj -C *.java ...
OR
  gdb -- gdb -C *.java ...

Everything after the `--' are command-line arguments for the inferior.
Note that you put the program's name after the `--' -- this lets you
insert the `gdb' command into an existing command-line without editing
(an important property if you are doing this programmatically).

In invisible mode, gdb would connect its stdin, stdout, and stderr
directly to the inferior, do whatever initialization it needed, and
then run the program without user interaction.  (The I/O stuff is
needed because it lets you insert "gdb --invisible" into a pipeline.)

If the program crashed, or hit a breakpoint (gdb would still read
.gdbinit), then gdb would create its user interface: open a window,
connect to the user's terminal, whatever.

In non-invisible mode, gdb would start interactively as usual.

A long time ago (1992!) I used a debugger that had this feature.  It
was wonderful.  It eliminated an annoying step from the debugging
process.

In my situation I had a server launching various client programs,
which would then communicate with the server via stdin/stdout.  This
feature let me insert "sdb ..." into the client launch command and
debug the program in its natural environment.

These days I see a nice use for this feature in gcc.  When I debug
gcj, I often run `gcj -v blah blah blah', and the extract the jc1
command line from that output.  This is a pain, particularly if the
command-lines are long.  I'd much rather add a little debugging
feature to gcc that would let me tell it to run `gdb --invisible' on
the jc1 invocation.  Then, as Mo says, I could even do it via the make
command line.


Now it occurs to me that the visible/invisible split might not be the
best one.  It might be better to always go interactive, but still
connect the stdio streams (and any other open file descriptors, though
this is less important) to the inferior.  People can always just "r"
from there, perhaps via .gdbinit if they wanted.

Tom