From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fernando Nasser To: Brian Youmans <3diff@gnu.org> Cc: gdb-patches@sourceware.cygnus.com Subject: Re: authorship Date: Mon, 08 May 2000 09:33:00 -0000 Message-id: <3916EC24.6ABB63D2@cygnus.com> References: <200005081355.JAA19096@delysid.gnu.org> <3916CE20.774F4438@cygnus.com> <200005081544.LAA19526@delysid.gnu.org> X-SW-Source: 2000-05/msg00125.html 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 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 To: DJ Delorie 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: <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 -run 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 To: DJ Delorie 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 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: X-SW-Source: 2000-05/msg00130.html Content-length: 2832 >>>>> "Mo" == Mo DeJong 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 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: <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 To: Michael Meissner 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: <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!