This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: naming command arguments
- From: Michael Snyder <msnyder at redhat dot com>
- To: Andrew Cagney <ac131313 at ges dot redhat dot com>
- Cc: Anthony Green <green at redhat dot com>, gdb at sources dot redhat dot com
- Date: Fri, 26 Jul 2002 14:44:55 -0700
- Subject: Re: naming command arguments
- Organization: Red Hat, Inc.
- References: <1027556059.2082.179.camel@dhcppc2> <3D408887.70003@ges.redhat.com>
Andrew Cagney wrote:
>
> > I've been talking to some GDB users who are frustrated with some of
> > GDB's command syntax. My understanding is that optional command
> > arguments must be the last possible arguments, and they get dropped off
> > right to left. The problem is that some GDB commands have multiple
> > arguments, all of which make sense to be optional, but in no particular
> > order.
> >
> > So, for instance, the restore command looks something like:
> >
> > restore FILENAME [OFFSET [START [STOP]]]
> >
> > In this case, if you only want to specify the START argument, your
> > forced to give OFFSET argument.
> >
> > They're suggestion, which seems to make sense to me, is to introduce the
> > concept of named parameters for GDB commands. So, in my previous
> > example, they could simply write...
> >
> > restore FILENAME start:VALUE
> >
> > ...and let GDB make reasonable assumptions about OFFSET and STOP
> >
> > How do people feel about introducing these kinds of arguments to certain
> > GDB commands (like restore)?
>
> For this specific case, how does one differentiate between:
>
> start:1
>
> the source and line specification and:
>
> start:1
>
> the start:VALUE?
For this specific case, the command doesn't accept line specs.
Only integer expressions interpretted as addresses.
> GDB desperatly needs a command line syntax that better allows the
> specification of optional information but it needs to be chosen very
> carefully.
>
> Other options to consider:
>
> restore/start:VALUE FILE
> restore --start=VALUE FILE
>
> etc.
>
> Andrew