GDB needs a --cmdline option

[Mo DeJong]

On Mon, 8 May 2000, Andrew Cagney wrote:

> 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 it is you that identified two different issues.
I was only thinking about the first one.

1. A way to just run a program in gdb with command
line arguments passed in from the shell. The user
would not need to know anything about gdb commands
in order to use the --cmdline argument.

2. A way to pass in generic gdb commands in from
the command line.

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

Your "generic" approach requires knowledge of gdb
commands. I have no problem with "power users"
having a way to pass stuff in on the command line,
but I am more concerned with folks that are not
power users. There should be a simple "one liner"
way to start up a program inside gdb and run it
without know lots of gdb details.

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

Pure "dumb luck" there.

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

Yeah, there is no real reason to use a .gdbcmdline file
other than the fact that I just hacked the --cmdline
option to overload the --command=FILE option. I am
not a gdb hacker so I ws going for "get it working"
so that I could test out the idea. If you could
point me a some example code that would allow
me to create and "source" a buffer, that would
be great.

> 	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

Ok, I am not going to ask why.

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

Mo Dejong
Red Hat Inc.