This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [MI] -stack-list-variables
On Sunday 20 September 2009 Nick Roberts wrote:
> > ...The new command is called -stack-list-variables,
> > and it's checked in into CVS HEAD.
>
> I don't like this patch/commit for a couple of reasons. One reason I
> proposed such a command was to move away from the loose syntax that MI
> uses. In particular to move away from:
>
>
> `LIST ==>'
> ` "[]" | "[" VALUE ( "," VALUE )* "]" | "[" RESULT ( "," RESULT )* "]" '
>
> to
>
> `LIST ==>'
> ` "[]" | "[" VALUE ( "," VALUE )* "]" '
>
>
> to provide a more JSON-like syntax.
>
> As with -stack-list-locals, the new output can give something like:
>
> -stack-list-variables --no-values
> ^done,variables=[name="i",name="j",name="asdf",name="m",name="zxcv",name="qwert"]
>
> but to keep JSON-like syntax, this needs to be:
>
> -stack-list-variables --no-values
> ^done,variables=[{name="i"},{name="j"},{name="asdf"},{name="m"},{name="zxcv"},{name="qwert"}]
Well, with values printed, the output is:
-stack-list-variables --thread 1 --frame 0 --all-values
^done,variables=[{name="x",value="11"},{name="s",value="{a = 1, b = 2}"}]
and is therefore OK. It's no-values case that takes shortcuts. However,
I plan a follow-up patch really soon now that will make -stack-list-variables
output a block where each variable defined. As result, there will be
two attributes for each variable, and the output above will be used in
all cases, regardless of whether printing of values was requested.
> which leads to my second point:
>
> Which `variables' are the arguments and which are locals?
> Arguments might be a kind of local but they're not identical.
>
> How about the format below?:
>
> -stack-list-variables --no-values
> ^done,variables={args=[{name="i"},{name="j"}],
> locals=[{name="asdf"},{name="m"},{name="zxcv"},{name="qwert"}]}
Why would frontend care about which are locals and which are arguments? I don't
think I saw any GUI than distinguish between those in variables view. Even
if we decide this information is necessary, would it not be better to present it
like this:
^done,variables=[{name="i", arg="1"},{name="asdf"}]
as this format is more extensible in case some other frontend might need
even more finer details?
- Volodya