public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Tom Tromey <tom@tromey.com>
To: Philippe Waroquiers <philippe.waroquiers@skynet.be>
Cc: Andrew Burgess <andrew.burgess@embecosm.com>,
	 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: Fri, 31 Aug 2018 20:59:00 -0000	[thread overview]
Message-ID: <87h8jaz1zz.fsf@tromey.com> (raw)
In-Reply-To: <1535663976.7778.12.camel@skynet.be> (Philippe Waroquiers's	message of "Thu, 30 Aug 2018 23:19:36 +0200")

>>>>> "Philippe" == Philippe Waroquiers <philippe.waroquiers@skynet.be> writes:

Philippe> For what concerns the parenthesis based solution, it looks to not work
Philippe> for some cases.

Philippe> E.g. if I want to pass one argument (I am using single quotes to show the args
Philippe> I want in the below examples):
Philippe>     'a b) (c d'
Philippe> then I need to use:
Philippe>     some_user_defined (a b) (c d)
Philippe> but that is the same notation as if I want to pass 2 arguments
Philippe>     'a b'  and 'c d'

Can you think of an actual example where this would be useful?
My feeling is that there isn't one, though I'd be interested in
tricky-but-plausible counter-examples.

This feeling is why I'm generally ok with Andrew's idea.

Philippe> And it would be nice if the mechanism used to quote args would
Philippe> be compatible between user defined commands and native gdb commands.

There is no universal quoting in gdb.  Instead there are 3 common cases,
plus the extras (neglecting MI, which is totally different and not
relevant here):

1. Commands that take an expression.  These are things like "print".
   Expressions are passed to the language parser, but language parsers
   have to follow some gdb rules: optionally terminate parsing at a
   top-level (unparenthesized) comma, and also terminate parsing at "if"
   or some other things (there is a mildly odd case for Ada tasks).

2. Commands that take a linespec.  These can also take an expression via
   the "*" linespec, so linespecs end up following some expression
   rules.  Often there are expressions after the linespec too, like
     break LINESPEC if EXPR
   or
     dprintf LINESPEC, "string", EXPR, EXPR...

3. Commands that use gdb_argv (or libiberty's buildargv, which is the
   same thing).  These respect some simple quoting.  However, the
   quoting is very simple, not like what you might expect from the
   shell, for example I don't think you can quote an embedded quotation
   mark of the same kind (that is, no "this has \"quotes\"").

4. Everything else.  gdb commands are just given a string and some do
   whatever the author liked.

Philippe> I have not understood the reference given by Tom that expressions
Philippe> are terminated with ,  and that parenthesis stops this termination.
Philippe> Is that described somewhere in the doc ?
Philippe> The doc (or an example if this is not documented) will help
Philippe> me to understand.

I think it's largely undocumented, since some of these quirks are just
constraints arising from gdb's implementation choices.

Not having any rhyme or reason to command argument parsing has good and
bad facets.

The good is that the generally DWIM nature of commands means that
usually you don't have to contort yourself to satisfy some parser.
Like, you can "break foo.c:93" or "break function" rather than something
like the old dbx "stop in" / "stop at" split.

The bad of course is that you may sometimes want to quote something and
not have any idea of how to do it: because there's no consistency;
because the gdb_argv idea was not really thought through (that's my
conclusion, I don't know the actual story); or perhaps because you've
just tripped across some command that was implemented in a particularly
bad way.

Now, it would be great to fix this, at least for some subset of things.
I find it hard to see a way forward, though.  Breaking compatibility
(see my post upthread) is unpleasant, unless maybe it is done in a very
dramatic way, coupled with a major version bump and some kind of huge
warning for users -- but that's also very hard to implement and release.

One idea is to add a new standard way to parse arguments, for new
commands.  But of course then gdb just has 5 ways to do it ... :(

Tom

  reply	other threads:[~2018-08-31 20:59 UTC|newest]

Thread overview: 26+ 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
2018-08-15 14:39 ` [PATCH 2/2] gdb: Allow parenthesis to group arguments to user-defined commands Andrew Burgess
2018-08-15 18:24   ` 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
2018-08-31 20:59                   ` Tom Tromey [this message]
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=87h8jaz1zz.fsf@tromey.com \
    --to=tom@tromey.com \
    --cc=andrew.burgess@embecosm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=philippe.waroquiers@skynet.be \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).