GDB needs a --cmdline option
Sun May 7 17:10:00 GMT 2000
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
> 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
> 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.
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.
Red Hat Inc.
More information about the Gdb-patches