This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch[ Improve the error messages of tvariable command
- From: "Abid, Hafiz" <hafiz_abid at mentor dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: <gdb-patches at sourceware dot org>, <palves at redhat dot com>
- Date: Wed, 13 Feb 2013 16:58:17 +0000
- Subject: Re: [patch[ Improve the error messages of tvariable command
- References: <1360688372.8583.1@abidh-ubunto1104> <511BC3AA.60708@redhat.com>
On 13/02/13 16:47:38, Pedro Alves wrote:
I somewhat remember investigating this, and writing a longer
rationale for the change -- the gist of it being not
handling tsv name as expressions. Can you dig it out from
the internal archives and repost including that info? It'd
be good for posterity.
--
Pedro Alves
Here is what I found. Is it what you were expecting?
--
Here's a fix for issue #8161, which is about the "tvariable" returning
errors on invalid and tsv names. E.g.,
Temporary breakpoint 1, main () at a.cc:2
2 int x = 1;
(gdb) tvar x
Syntax must be $NAME [ = EXPR ]
(gdb) tvar y
No symbol "y" in current context.
The problem is the use of parse_expression to parse the tvariable's
name. We could merely always catch errors thrown from within
parse_expression, and issue a "usage" error, but it wouldn't cover
all cases correctly. E.g.,
(gdb) tvar x = nonexistingvariable
is an invalid expression, not invalid syntax.
I also noticed that
(gdb) tvar x = 1 = 1
would be incorrectly accepted.
Given that the comand is documented to only take an expression
on the right side of the '=', it seems that whatever is on
the left side of the '=' should not be treated as an expression, but
literaly as "$NAME". That's what the patch does.
MI now shares the same name validations as the CLI variant.
--
Regards,
Abid