From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2159 invoked by alias); 13 Feb 2013 17:01:45 -0000 Received: (qmail 2108 invoked by uid 22791); 13 Feb 2013 17:01:37 -0000 X-SWARE-Spam-Status: No, hits=-7.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 13 Feb 2013 17:01:27 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r1DH1PmW007454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Feb 2013 12:01:25 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r1DH1NEk024108; Wed, 13 Feb 2013 12:01:24 -0500 Message-ID: <511BC6E3.6060405@redhat.com> Date: Wed, 13 Feb 2013 17:01:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Abid, Hafiz" CC: gdb-patches@sourceware.org Subject: Re: [patch[ Improve the error messages of tvariable command References: <1360688372.8583.1@abidh-ubunto1104> <511BC3AA.60708@redhat.com> <1360774697.2842.2@abidh-ubunto1104> In-Reply-To: <1360774697.2842.2@abidh-ubunto1104> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2013-02/txt/msg00315.txt.bz2 On 02/13/2013 04:58 PM, Abid, Hafiz wrote: > 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. Ah, that's it. Thanks for digging it out. > MI now shares the same name validations as the CLI variant. -- Pedro Alves