This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 2/2] gdb: Allow parenthesis to group arguments to user-defined commands
* Philippe Waroquiers <philippe.waroquiers@skynet.be> [2018-08-28 22:28:57 +0200]:
> On Tue, 2018-08-28 at 19:43 +0100, Andrew Burgess wrote:
> > * Tom Tromey <tom@tromey.com> [2018-08-28 09:53:52 -0600]:
> >
> > > > > > > > "Andrew" == Andrew Burgess <andrew.burgess@embecosm.com> writes:
> > >
> > > Andrew> So, my suggestion deliberately avoids using quotes or backslashes as
> > > Andrew> these are bogged down in the existing code. And using (...) is fairly
> > > Andrew> intuitive given GDBs C like expression handling, personally I'd rather
> > > Andrew> write:
> > > Andrew> my_command ({unsigned long long} &global_var)
> > > Andrew> than:
> > > Andrew> my_command {unsigned\ long\ long}\ &global_var
> > >
> > > FWIW I tend to agree with your logic here.
> > >
> > > User-defined argument parsing is broken (and I think there's at least
> > > one bug in bugzilla about this), but at the same time, making breaking
> > > changes seems unfriendly. Your approach doesn't seem to be breaking
> > > anything that is likely to be actually used.
>
> I do not think a \ followed by a space will create a lot of incompatibilities.
> i
> .e. that someone would type
> some_user_defined_command a\ b
> to give 2
> different args to the command.
No, and what they get at the moment is a single argument, which is:
a\ b
including the backslash and the space. Is this correct, or useful? I
suspect not, but my instinct in these cases is not to mess with things
without good reason, and I didn't have a good reason.
>
> For single quotes: it is unlikely that someone types something like
> some_user_defined_command 'abc def'
> and was expecting the user defined command to receive two args.
I agree, and what they get right now is:
'abc def'
including the quotes.
> What is however a lot more likely is
> some_user_defined_command 'a'
> and this command expects to receive a character value.
Which is more or less what you get:
'a'
> So, yes, single quotes has more potential to create
> incompatibilities.
I guess that depends on what you're proposing the argument should
evaluate too.
>
> On the downside, quoting with parenthesis is something very peculiar
> (is there some other tool/shell/... using this convention ?).
I guess I never saw it as quoting, just grouping an expression
together. I think I see GDB as mostly consuming C like expressions,
which is why using () seemed natural enough. Coincidentally the users
I'm working with initially tried () too (without prompting from me) so
my focus group of 2 all agreed with me ;-)
>
> And from a previous discussion with Pedro, he indicated that
> some commands in gdb already are using single quotes.
> The 'Not sure' below is a quote of Pedro :), replying to a suggestion
> I gave to let the user tell explicitly if an arg was quoted or not.
> > * have a way to (explicitely) quote an argument e.g.
> > info var -Qt 'long int' regexpofsomevars
> > where -Q indicates that the next "value argument" is
> > explicitely quoted.
>
> Not sure we need that -Q. We can support optional quotes, and
> tell users to add quotes if necessary? That's what we've done
> since forever in linespecs and expressions, for example.
>
> It is based on this that I used single quotes in the
> info var/func/arg/local -t TYPEREGEXP NAMEREGEXP
> patch.
>
> > Given that the argument passing for user-defined functions is pretty
> > self contained we could, conceivably, implement a whole new system and
> > have a switch to select between them... the existing code does seem
> > rather odd.
> >
> > But ideally, I'd like that to be a project for another day.
> And we also have the 'generalised arg parser' prototype that Pedro has
> in a corner.
>
> IMO, clearly, what to do is unclear :).
I agree, except I need to figure out some clarity in order to resolve
the real issue I have :)
I think that you're arguing in favour of reworking the argument
passing to user-defined commands. I'm not entirely sure exactly what
rules you're proposing we adopt though.
Maybe you could help me work through a few examples, in the following
table I've outlined a few examples, and have the following questions:
[1] What argument(s) would be passed under the new scheme?
[2] What argument(s) would be passed under the new scheme?
[3] How would I write {unsigned long} &var to pass this as a single
argument? If with quotes, how does this relate to 1 & 2?
| Input | Current Arguments(s) | Proposed Argument(s) |
|----------------------+----------------------+----------------------|
| a b | a | a |
| | b | b |
|----------------------+----------------------+----------------------|
| "a b" | "a b" | [1] |
|----------------------+----------------------+----------------------|
| 'a b' | 'a b' | [2] |
|----------------------+----------------------+----------------------|
| {unsigned long} &var | {unsigned | |
| | long} | N/A |
| | &var | |
|----------------------+----------------------+----------------------|
| [3] | | |
|----------------------+----------------------+----------------------|
In general I'm happy to rework this part of GDB, but ideally I'd like
some feedback from a global maintainer that such a change, which might
would break backward compatibility, would be acceptable...
Thanks,
Andrew