From: Vladimir Prus <vladimir@codesourcery.com>
To: gdb@sources.redhat.com
Subject: [MI] argv/argc/args
Date: Wed, 25 Jun 2008 09:06:00 -0000 [thread overview]
Message-ID: <200806251306.27720.vladimir@codesourcery.com> (raw)
In GDB 6.8 codebase, there were 3 different ways an MI command can be processed:
1. Sneaking via CLI directly (calling execute_command)
2. Calling a function, that takes argc/argv pair
3. Calling a function, that takes a string 'args' parameter with
the raw part of MI command string after the command name.
Some time ago, I've checked in a patch to remove (3), to clarify the
code. Dan has raised concerns about backward compatibility, so here's
an attempt to analyze the change afresh.
The following is the complete list of command affected by my patch:
-exec-run
-exec-next
-exec-next-instruction
-exec-step
-exec-step-instruction
-exec-finish
-exec-until
-exec-return
-exec-continue
-exec-interrupt
-target-download
-target-select
The trivial ones are:
-exec-finish
-exec-interrupt
Those commands don't take any parameter at all, so no issues.
The following commands are "easy":
-exec-next
-exec-next-instruction
-exec-step
-exec-step-instruction
-exec-continue
They are not documented to take any parameters. In practice, they will
accept a parameter -- telling either the number of steps to perform,
or the number of times to ignore a breakpoint we're stopped at. We'll have
a problem here only if frontend indeed passes extra parameter, and that
parameter is expression (not a simple number) and that expression has
spaces. Seems to me this is unlikely.
The bad ones are:
-exec-until
-target-download
-target-select
Those are documented to accept a parameter, and, furthermore, this parameter may
contain spaces. So, if we strip quoting at MI level, we pass unquoted string futher.
For example, -exec-until eventually calls until_break_command, which calls
decode_line_1, and if we pass a filename with spaces to -exec-until and quotes
are stripped before calling until_break_command, this will not work. The other
two commands are even more risky.
The gray ones are:
-exec-run
this is not documented to take a parameter but may. I think, though, that
frontends probably use -exec-arguments, instead of relying on this undocumented
behaviour.
-exec-return
This one is not documented as returning an expression -- this is probably a
documentation bug. Frontend passing an argument to this command will be broken
if it tries to pass an unquoted expression with spaces, which is probably
not common.
So, we have 3 commands for which requiring the input to be quoted per MI rules
will cause issues; and fixing those issues will require changing other parts of
GDB to avoid parsing filenames, which is risky at this point. It appears, that
instead of reverting my original patch, we can just path those 3 commands
via CLI directly. Does the plan sound reasonable?
- Volodya
next reply other threads:[~2008-06-25 9:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-25 9:06 Vladimir Prus [this message]
2008-06-25 14:45 ` Marc Khouzam
2008-06-27 13:53 ` Daniel Jacobowitz
2008-06-27 14:39 ` Vladimir Prus
[not found] <200806251907.58610.vladimir@codesourcery.com>
2008-06-25 17:21 ` Marc Khouzam
2008-06-25 17:28 ` Vladimir Prus
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=200806251306.27720.vladimir@codesourcery.com \
--to=vladimir@codesourcery.com \
--cc=gdb@sources.redhat.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