This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
[MI] argv/argc/args
- From: Vladimir Prus <vladimir at codesourcery dot com>
- To: gdb at sources dot redhat dot com
- Date: Wed, 25 Jun 2008 13:06:27 +0400
- Subject: [MI] argv/argc/args
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