Re: authorship

[Fernando Nasser <fnasser@cygnus.com>]

Brian Youmans wrote:
> 
> RMS's opinion was that it was better to give authorship credits to
> individuals rather than to the businesses they work for.  So perhaps
> we should rather go to something like "Richard Stallman,
> Roland Pesch, and Stan Shebs".  The general idea is that the
> principal authors should get authorship credit, while everyone
> else gets thanks, more or less effusive, inside.
> 
Sorry if I mislead you.  John Gilmore and Stan Shebs appear as authors
of the "Gdb Intelnals" manual, not the "Debugging with Gdb".
I believe Stan may have contributed a lot to the manual (as many others),
but his name was never in there.

Following RMS's idea, we could keep the authors and have "Chapter" authors,
as they do in books.  This way the idea of giving proper credit to individuals
is acomplished. This would not apply to minor changes or additions, which are to
be treated as we treat code contributions.  They go into the general
acknowledgement section.

-- 
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 dj@delorie.com Mon May 08 09:38:00 2000
From: DJ Delorie <dj@delorie.com>
To: 3diff@gnu.org
Cc: fnasser@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: authorship
Date: Mon, 08 May 2000 09:38:00 -0000
Message-id: <200005081637.MAA18610@envy.delorie.com>
References: <200005081355.JAA19096@delysid.gnu.org> <3916CE20.774F4438@cygnus.com> <200005081544.LAA19526@delysid.gnu.org>
X-SW-Source: 2000-05/msg00127.html
Content-length: 163

> So perhaps we should rather go to something like "Richard Stallman,
> Roland Pesch, and Stan Shebs".

Or "RS, RP, SS, et al." to indicate other unnamed authors.
From fnasser@cygnus.com Mon May 08 09:57:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: DJ Delorie <dj@delorie.com>
Cc: mdejong@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: GDB needs a --cmdline option
Date: Mon, 08 May 2000 09:57:00 -0000
Message-id: <3916F209.389D51A9@cygnus.com>
References: <Pine.SOL.3.91.1000507154133.21631E-100000@cse.cygnus.com> <200005081633.MAA18580@envy.delorie.com>
X-SW-Source: 2000-05/msg00128.html
Content-length: 2200

OK, we do have a problem with the gdb command line invocation.

We are aware of that and we have not fixed it because:
1) It is not trivial
2) We don't want to make things even worse.

One of the problems is that we have a syntax, well established,
documented everywhere, used in who knows how many scripts,
that has the core file name or the process id following the
executable file specification.  That was a mistake, but it was
made long time ago and we have to live with it.

Now people want to:

1) Specify gdb command in the command line.

2) Pass the arguments to the program to be debugged on the gdb
   command line.

The first one is not so trivial as it seems because there are some
ordering of command execution that gdb will have to take care of.
We do it for the .gdbinit commands already, but the user will have
to be aware of this detail, unfortunately.

The second one is just a syntax problem.  As Andrew says, if we had the
first one implemented you could just use a "set args".  But them there
is the globbing issues...


Based on what DJ wrote, we could do something similar to dbx.

gdb <gdb command line switches> -run <command line>

The first token would be the program to run and everything else
would be set as arguments for that program (implicit "set args").

The -run must be (obviously) the last gdb command line switch.

Gdb will silently exit on program exit, with the same return code
as the inferior ended.


Opinions?  Volunteers?




DJ Delorie wrote:
> 
> > I have been running into a problem with gdb that it seems
> > would be nicely solved with a new command line option --cmdline.
> 
> SunOS's debugger could do this:
> 
>         dbx -r program args ...
> 
> *If* there was a problem with the program, the debugger would take
> over.  Otherwise, the program ran as usual, and exited as usual, and
> the debugger quietly stayed out of the way.
> 
> I used that in Makefiles a lot, and it would really come in handy
> in gcc (-B'dbx -r ./' ?)

-- 
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 fnasser@cygnus.com Mon May 08 09:59:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: DJ Delorie <dj@delorie.com>
Cc: 3diff@gnu.org, gdb-patches@sourceware.cygnus.com
Subject: Re: authorship
Date: Mon, 08 May 2000 09:59:00 -0000
Message-id: <3916F261.EB8FAD0C@cygnus.com>
References: <200005081355.JAA19096@delysid.gnu.org> <3916CE20.774F4438@cygnus.com> <200005081544.LAA19526@delysid.gnu.org> <200005081637.MAA18610@envy.delorie.com>
X-SW-Source: 2000-05/msg00129.html
Content-length: 480

DJ Delorie wrote:
> 
> > So perhaps we should rather go to something like "Richard Stallman,
> > Roland Pesch, and Stan Shebs".
> 
> Or "RS, RP, SS, et al." to indicate other unnamed authors.

Also very appropriate.  I would still credit complete chapters though.

-- 
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 tromey@cygnus.com Mon May 08 10:00:00 2000
From: Tom Tromey <tromey@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: GDB needs a --cmdline option
Date: Mon, 08 May 2000 10:00:00 -0000
Message-id: <871z3doune.fsf@cygnus.com>
References: <Pine.SOL.3.91.1000507154133.21631E-100000@cse.cygnus.com>
X-SW-Source: 2000-05/msg00130.html
Content-length: 2832

>>>>> "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
From meissner@cygnus.com Mon May 08 10:10:00 2000
From: Michael Meissner <meissner@cygnus.com>
To: tromey@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: GDB needs a --cmdline option
Date: Mon, 08 May 2000 10:10:00 -0000
Message-id: <20000508131024.42535@cse.cygnus.com>
References: <Pine.SOL.3.91.1000507154133.21631E-100000@cse.cygnus.com> <871z3doune.fsf@cygnus.com>
X-SW-Source: 2000-05/msg00131.html
Content-length: 1178

On Mon, May 08, 2000 at 10:48:21AM -0600, Tom Tromey wrote:
> 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.)

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.

I do like the concept of gdb --invisibile.  For those of us who greatly prefer
the text interface to a gui interface, you probably want the ability for the
gdb control console to be something other than stdin/stdout.

-- 
Michael Meissner, Cygnus Solutions, a Red Hat company.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482
From fnasser@cygnus.com Mon May 08 10:39:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: Michael Meissner <meissner@cygnus.com>
Cc: tromey@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: GDB needs a --cmdline option
Date: Mon, 08 May 2000 10:39:00 -0000
Message-id: <3916FBE7.ECD328A5@cygnus.com>
References: <Pine.SOL.3.91.1000507154133.21631E-100000@cse.cygnus.com> <871z3doune.fsf@cygnus.com> <20000508131024.42535@cse.cygnus.com>
X-SW-Source: 2000-05/msg00132.html
Content-length: 1182

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).

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).

-- 
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 11:10: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:10:00 -0000
Message-id: <200005081809.OAA20154@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/msg00133.html
Content-length: 1220

I'm afraid that crediting individual chapters would just create more
work and disputes.  Certainly going back right now and determining who wrote
what chapter sounds like work to me.  If I had to figure all that out,
I'd demand an authorship listing myself! (just joking)

I will ask RMS about the legality/propriety of the "et al" addition or
how otherwise to recognize lesser contributions.

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?

                                    Brian Youmans
                                    FSF Office Staff

 Free Software Foundation     |  A 501 (c) 3 not-for-profit
 59 Temple Place, Suite 330   |  corporation; contributions
 Boston, MA 02111-1307  USA   |  are tax-deductible in the
                              |  USA.
 voice: +1-617-542-5942       |
 fax:   +1-617-542-2652       |  Support Project GNU...
 web:   http://www.gnu.org    |  GNU's Not Unix!