Re: GDB needs a --cmdline option

[Andrew Cagney <ac131313 at cygnus dot com>]

Mo DeJong wrote:

> gdb gcj --cmdline "-C *.java gnu/gcj/convert/*.java gnu/gcj/*.java"
> 
> So I went off and hacked something together to do
> that. The patch for gdb from the sourceware CVS is
> appended to this email.
> 
> So question 1 is, do other folks think this --cmdline
> option is a good idea?

I think you've identifed two separate problems:

	o	there should be a way of passing individual
		commands to GDB on the command line
		(rather than having to shove them in a file)

	o	there should be a convenient reliable mechanism
		for passing commands through on the command
		line

As your patch currently stands, it sits half way between the two. 
Rather than your --cmdline what about a more generic:

	gdb ggg ..  --this-is-a-command "set args *.java
gnu/gcj/convert/*.java..." ...

as a more convenient way of passing in general commands on the command
line (which can include set args).  For the argument list, perhaphs: 

	$ gcj -C *.java gnu/gcj/convert/*.java gnu/gcj/*.java
	$ gdb -- !$

However, I should note that this last one isn't trivial as the code
would need to escape the accumulated arguments so that they are not
re-evaluated by the sub-shell.  For that reason, just the first, and far
more generic option might be the better thing to persue.

An important issue your patch does address (yow!), is the need to retain
evaluation ordering.  The implied ordering of:

	gdb ggg -x file-set-args --cmdline ... -x file-set-args

must be retained.

> If you answered yes on question 1, then what could be
> done to improve the patch so that it is up to
> gdb standards? I heard from a couple of folks that
> it might not be a good idea to clobber an existing
> .gdbcmdline file (if it existed) and that it might
> be better to remove the file after it was sourced.

I'd suggest the following:

	o	Instead of creating/clibering the .gdbcmdline
		file, I think you could implement this using
		just local buffering.  An internal list of
		commands say?  I can't see any reason to
		create a file. (the current directory may
		be readonly, the file may exist, ....)

	o	Rather than falling through to the ``-x'' code
		(bad for long-term maintainability) I'd suggest
		thinking about an improved mechanism that allows
		you to accumulate both commands and scripts.

enjoy,
	Andrew

PS: It's ``xyz ()'' not ``xyz()'' and yes it does take some getting
accustomed to :-)
PPS: Once integrated I think the idea will be wildly popular.