Re: GDB needs a --cmdline option

Re: GDB needs a --cmdline option

[Tom Tromey]

>>>>> "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

Re: GDB needs a --cmdline option

[Mark Kettenis]

   Date: Mon, 08 May 2000 13:39:51 -0400
   From: Fernando Nasser <fnasser@cygnus.com>

This is getting a bit off topic, but I couldn't resist to respond :-)

   Michael Meissner wrote:
   > 
   > Just as a note, when I was at DG many years ago, the debugger
   > group there added a feature where a program could invoke the
   > debugger as a child whenever it wanted to be debugged (usually in
   > the case for long live processes, especially daemons).  I recall
   > some people adding such a call to AOS/VS's equivalent of a signal
   > handler, so you could just hit ^C to start up the debugger.
   > 

   If you modify abort() do that it will try to activate the debugger
   if a certain environment variable is set we could work like MS
   stuff (if the idea of mimicking MS offends you, just remember they
   probably copied it from someone else, it may have even been from
   some Unix variant).

We have something like that on the Hurd :-).  When a program gets a
fatal signal (for example as a result of calling abort()), it contacts
a special crash server.  This crash server is supposed to do whatever
is appropriate like producing a core dump, but that's not implemented
right now.  Instead we suspend the process such that you can attach
GDB to it.  The nice thing is that this means that the process is
still mostly intact, including its communication channels with other
processes.

It would be a piece of cake to write a crash server that fires up GDB
for you.  The nice thing is that the user can specify what crash
server should be used by using an environment variable.  So you don't
need to be the system administrator to change it.

   This would only make sense for foreground jobs though.  Daemons are
   probably restricted to core files (which is not that bad -- with
   the right log facility and a core file one has a great chance to
   reproduce the problem on a subsequent debugger controlled run).

The current crash server allows you to specify different actions for
orphaned processes.

However, this doesn't make the command line option unnecessary.  If
the process crashed, it may be hard to reconstruct exactly why it
crashed (I have some experience with debugging a broken calloc()
implementation :-().

Mark
From 3diff@gnu.org Mon May 08 11:21:00 2000
From: Brian Youmans <3diff@gnu.org>
To: fnasser@cygnus.com
Cc: dj@delorie.com, gdb-patches@sourceware.cygnus.com
Subject: Re: authorship
Date: Mon, 08 May 2000 11:21:00 -0000
Message-id: <200005081820.OAA20194@delysid.gnu.org>
References: <200005081355.JAA19096@delysid.gnu.org> <3916CE20.774F4438@cygnus.com> <200005081544.LAA19526@delysid.gnu.org> <200005081637.MAA18610@envy.delorie.com> <3916F261.EB8FAD0C@cygnus.com>
X-SW-Source: 2000-05/msg00135.html
Content-length: 148

"et al." sounds like it is a shortened form of the list, but we wouldn't have
the long version anywhere.  How about "and others"?


- Brian Y., FSF
From fnasser@cygnus.com Mon May 08 11:47:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: Brian Youmans <3diff@gnu.org>
Cc: dj@delorie.com, gdb-patches@sourceware.cygnus.com
Subject: Re: authorship
Date: Mon, 08 May 2000 11:47:00 -0000
Message-id: <39170BA9.687A988E@cygnus.com>
References: <200005081355.JAA19096@delysid.gnu.org> <3916CE20.774F4438@cygnus.com> <200005081544.LAA19526@delysid.gnu.org> <200005081637.MAA18610@envy.delorie.com> <3916F261.EB8FAD0C@cygnus.com> <200005081809.OAA20154@delysid.gnu.org>
X-SW-Source: 2000-05/msg00136.html
Content-length: 973

Brian Youmans wrote:
> 
> Are people agreed that it is reasonable to add Stan Shebs as an
> author?  (Stan being conveniently on vacation, he won't see this until
> he gets back.)  He seems to have been the chief person that I have
> been dealing with about the manual for the past several years.
> Has he been chiefly responsible for the recent additions to the manual,
> such as the gdb/mi chapter?
> 
Yes, Stan has maintained it for several years, so my personal opinion is
that he deserves the credit.

The gdb/mi chapter was written by the authors of that interface 
(Andrew, Elena and myself).  I guess we are some of the "and others" :-)

There are other "and others" authored chapters as well, being 13, 14 and 18
the ones that come to my mind now.

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From 3diff@gnu.org Mon May 08 12:12:00 2000
From: Brian Youmans <3diff@gnu.org>
To: fnasser@cygnus.com
Cc: dj@delorie.com, gdb-patches@sourceware.cygnus.com
Subject: Re: authorship
Date: Mon, 08 May 2000 12:12:00 -0000
Message-id: <200005081911.PAA20484@delysid.gnu.org>
References: <200005081355.JAA19096@delysid.gnu.org> <3916CE20.774F4438@cygnus.com> <200005081544.LAA19526@delysid.gnu.org> <200005081637.MAA18610@envy.delorie.com> <3916F261.EB8FAD0C@cygnus.com> <200005081809.OAA20154@delysid.gnu.org> <39170BA9.687A988E@cygnus.com>
X-SW-Source: 2000-05/msg00137.html
Content-length: 442

We should definitely list acknowledgements like that
explicitly in the contributors section:  "Thanks go to
George Washington and Abraham Lincoln for contributing the
chapter 'Using GDB on President's Day'" (or something like that.)

Whether we should also put authors on the chapter itself,
I don't know.  I don't think that is our usual practice at the FSF.
But, it is not a bad idea.  I've asked RMS for his opinion.

- Brian Youmans, FSF
From dan@cgsoftware.com Mon May 08 14:44:00 2000
From: Daniel Berlin <dan@cgsoftware.com>
To: Christopher Blizzard <blizzard@mozilla.org>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [Fwd: gdb patch]
Date: Mon, 08 May 2000 14:44:00 -0000
Message-id: <Pine.LNX.4.10.10005081443280.19102-100000@propylaea.anduin.com>
References: <3916DC7C.D17FE386@mozilla.org>
X-SW-Source: 2000-05/msg00138.html
Content-length: 775

Yes, we talked about it, and that was the general consensus.
However, i tried for about a week to find a way to make this the default,
and still have other things (like - and +) work, with no luck.
So if everyone likes, it can be merged, just not made the default.

On Mon, 8 May 2000, Christopher Blizzard wrote:

> Did anyone merge this in?  I thought that the general consensus was that
> it was a good thing.
> 
> --Chris
> 
> -------- Original Message --------
> Subject: gdb patch
> Date: Mon, 1 May 2000 08:24:52 -0400
> From: "Jim Nance" <jnance@nortelnetworks.com>
> To: blizzard@redhat.com
> 
> Hi Chris,
>     I have updated my gdb "list -w" patch to work with the gdb from RH
> 6.2.
> Could you pass it on to whereever it might need to go?
> 
> Thanks,
> 
> Jim

Re: GDB needs a --cmdline option

[Tom Tromey]

>>>>> "Fernando" == Fernando Nasser <fnasser@cygnus.com> writes:

Fernando> But gdb will still read the .gdbinit file and, if you put a
Fernando> "b _exit" in there gdb will fire up as you want.

Fernando> Is that acceptable?

It seems like it wouldn't be too much work to add a `--interactive'
option which will do all the setup but also ensure that you get a
command prompt.  Having an invisible mode is definitely nice.  But
sometimes pre-editing .gdbinit is a PITA.

Tom

Re: GDB needs a --cmdline option

[Tom Tromey]

>>>>> "Fernando" == Fernando Nasser <fnasser@cygnus.com> writes:

Fernando> For now, this will force -nw (non-GUI mode).

Why?  This feature is actually *more* useful with a GUI gdb.

Tom

Re: GDB needs a --cmdline option

[Tom Tromey]

>>>>> "Fernando" == Fernando Nasser <fnasser@cygnus.com> writes:

Fernando> What Tom wants is a way to "set args" from the command line.

No, I think it's more than that.
It lets me insert a `gdb' call directly into a pipeline like `--run'.
This mode would still handle stdin/out/err redirection issues like --run.
It would just let me debug directly instead of pre-editing.

Fernando> This seems more like a convenience though. 

Sometimes convenience is important.

Tom