From: Philippe Waroquiers <philippe.waroquiers@skynet.be>
To: Andrew Burgess <andrew.burgess@embecosm.com>
Cc: Tom Tromey <tom@tromey.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH 2/2] gdb: Allow parenthesis to group arguments to user-defined commands
Date: Thu, 30 Aug 2018 21:19:00 -0000 [thread overview]
Message-ID: <1535663976.7778.12.camel@skynet.be> (raw)
In-Reply-To: <20180828232948.GK32506@embecosm.com>
On Wed, 2018-08-29 at 00:29 +0100, Andrew Burgess wrote:
>
> 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...
Humph, now I understand that user defined commands already handle
specially single and double quotes, as you explained above.
This seems not documented in the gdb documentation, which tells
that 'Note the arguments are text substitutions, so they may
reference variables, use complex expressions, or even perform inferior
functions calls.' I have not found a description of this single and double
quote behaviour.
Maybe the only thing we might need is something like:
$unquoted_arg1 or something like that to allow to remove the quotes
inside the user defined command, when desired ?
Or as you suggested, some new flags to the define command, such as
define some_command -unquote_arg3
would indicate that if arg3 is a single quoted argument as in your table
above, that it must be given without the quote to some_command.
For what concerns the parenthesis based solution, it looks to not work
for some cases.
E.g. if I want to pass one argument (I am using single quotes to show the args
I want in the below examples):
'a b) (c d'
then I need to use:
some_user_defined (a b) (c d)
but that is the same notation as if I want to pass 2 arguments
'a b' and 'c d'
So, the parenthesis mechanism would need escaping or something like that,
to allow a general grouping. As it stands now, it only works
based on the assumption that the content inside the parenthesis
Still, it looks strange to me that we introduce another mechanism
on top of the single/double quotes to quote.
And it would be nice if the mechanism used to quote args would
be compatible between user defined commands and native gdb commands.
I have not understood the reference given by Tom that expressions
are terminated with , and that parenthesis stops this termination.
Is that described somewhere in the doc ?
The doc (or an example if this is not documented) will help
me to understand.
Philippe
next prev parent reply other threads:[~2018-08-30 21:19 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-15 14:39 [PATCH 0/2] " Andrew Burgess
2018-08-15 14:39 ` [PATCH 1/2] gdb: Make testnames unique in gdb.base/commands.exp Andrew Burgess
2018-08-30 15:26 ` Tom Tromey
[not found] ` <eaa6d3a2975194a7ef3a2aa40e335c7986b205d8.1534343840.git.andrew.burgess@embecosm.com>
2018-08-15 18:24 ` [PATCH 2/2] gdb: Allow parenthesis to group arguments to user-defined commands Eli Zaretskii
2018-08-25 19:32 ` Philippe Waroquiers
2018-08-25 20:53 ` Philippe Waroquiers
2018-08-25 22:43 ` Andrew Burgess
2018-08-28 15:54 ` Tom Tromey
2018-08-28 18:43 ` Andrew Burgess
2018-08-28 20:29 ` Philippe Waroquiers
2018-08-28 23:29 ` Andrew Burgess
2018-08-30 2:19 ` Tom Tromey
2018-08-30 21:19 ` Philippe Waroquiers [this message]
2018-08-31 20:59 ` Tom Tromey
2018-09-01 11:10 ` Philippe Waroquiers
2018-09-01 14:20 ` Tom Tromey
2018-09-01 15:36 ` Philippe Waroquiers
2018-08-30 2:26 ` Tom Tromey
2018-09-06 23:29 ` [PATCHv2] gdb: Rewrite argument handling for " Andrew Burgess
2018-09-07 6:31 ` Eli Zaretskii
2018-09-07 20:36 ` Tom Tromey
2018-09-07 22:47 ` Andrew Burgess
2018-09-08 6:27 ` Eli Zaretskii
2018-09-08 5:35 ` Philippe Waroquiers
2018-09-08 14:33 ` Andrew Burgess
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1535663976.7778.12.camel@skynet.be \
--to=philippe.waroquiers@skynet.be \
--cc=andrew.burgess@embecosm.com \
--cc=gdb-patches@sourceware.org \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox