From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127436 invoked by alias); 17 Feb 2020 14:39:36 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 127422 invoked by uid 89); 17 Feb 2020 14:39:35 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=H*f:sk:92c83e9, H*i:sk:92c83e9, H*MI:sk:92c83e9 X-HELO: mout.gmx.net Received: from mout.gmx.net (HELO mout.gmx.net) (212.227.15.18) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Feb 2020 14:39:34 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1581950370; bh=LBtoECZD9Iuumij5h+XYV4v2JdfeLERf2MBckz/QHsE=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=kqJFXrP9LzBhwLESpYZu7ENn47ZjrRfyi7isgFhovKLrw2xUbUsZKFI84Pi0FJQ0g XWLB0Pao3oWPvPqmzscuxKweWaWCh3wp/k/MDTP5Occ4qbsajEMEVZgYqifcBA2obd E5aw+UDP2fFjm/OPcG9wntp1hQrjlzYAuAQSejeo= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.64] ([46.223.148.137]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N7i8O-1jXrii1rbm-014hnY; Mon, 17 Feb 2020 15:39:30 +0100 Subject: Re: Is this a bug in gdb To: Luis Machado , gdb@sourceware.org References: <64aad0f5-5cee-63a6-18cc-1efdef1b1750@gmx.de> <6eb16386-eac9-cf5a-6cbe-813eae439df0@linaro.org> <92c83e9f-dff3-eb53-183d-46d495db0d51@linaro.org> From: =?UTF-8?Q?Volker_Wei=c3=9fmann?= Message-ID: <669a79cc-0675-6703-d2e4-687ca8eb863e@gmx.de> Date: Mon, 17 Feb 2020 14:39:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <92c83e9f-dff3-eb53-183d-46d495db0d51@linaro.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00042.txt.bz2 On 2/17/20 2:50 PM, Luis Machado wrote: > On 2/17/20 10:21 AM, Volker Wei=C3=9Fmann wrote: >> On 2/17/20 1:37 PM, Luis Machado wrote: >> >>> On 2/16/20 7:40 PM, Volker Wei=C3=9Fmann wrote: >>>> Hello, >>>> >>>> The help text of the watch command claims that the -l option >>>> watches the >>>> memory of the variable. When I tried this, I was surprised by the >>>> outcome (reproducible): >>>> >>>> >>>> (gdb) watch this->v_ >>>> Hardware watchpoint 2: this->v_ >>> >>> This command tells GDB to watch the value of this->v_, whatever >>> address &(this->v_) points to. That, of course, can change across the >>> execution of the program. >>> >>>> (gdb) watch -l this->v_ >>> >>> This command tells GDB to watch for changes in a particular location. >>> Since this->v_ is a value rather than a location, the error is thrown. >>> >>> The correct invocation would be ... >>>> A syntax error in expression, near `restrict *) 0x00007fffffffd398'. >>>> (gdb) >>>> >>>> Note: Using print &(this->v_) and=C2=A0 watch (char[8]) >>>> *outputoftheprintcommand worked. >>>> >>> >>> ... the above. It points to an address that will be watched. >>> >>>> >>>> I am asking you whether this is a bug in gdb or not, because if it >>>> is a >>>> bug in gdb, I will try to make a minimal example an file a bug report. >>> >>> I don't think it is a bug. But maybe the documentation isn't doing a >>> good enough job of making it clear how to invoke these commands? >> >> The reason why I thought that this might be a bug, is that I wrote the >> following toy program to test it: >> >> class MyClass { >> public: >> =C2=A0=C2=A0=C2=A0=C2=A0 int var =3D 0; >> =C2=A0=C2=A0=C2=A0=C2=A0 void member() { >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 var =3D 1; >> =C2=A0=C2=A0=C2=A0=C2=A0 } >> }; >> int main() { >> =C2=A0=C2=A0=C2=A0=C2=A0 MyClass obj; >> =C2=A0=C2=A0=C2=A0=C2=A0 obj.member(); >> =C2=A0=C2=A0=C2=A0=C2=A0 obj.var =3D 2; >> =C2=A0=C2=A0=C2=A0=C2=A0 return obj.var; >> } >> >> Lets say I want to know why my program returns 2 and not 1. I can do >> this like this: > > I went to actually read the documentation (by habit i only use watch > with the address itself) and i was mistaken. The -location option > should take care of grabbing the address of whatever expression you > passed to it. So ... > >> >> (gdb) break main.cpp:5 >> Breakpoint 1 at 0x118c: file main.cpp, line 5. >> (gdb) run >> Starting program: /home/volker/Sync/DatenVolker/bugreports/gdb/a.out >> >> Breakpoint 1, MyClass::member (this=3D0x7fffffffe344) at main.cpp:5 >> 5=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 var =3D 1; >> (gdb) watch -l this->var >> Hardware watchpoint 2: -location this->var >> (gdb) continue >> Continuing. >> >> Hardware watchpoint 2: -location this->var >> >> Old value =3D 0 >> New value =3D 1 >> MyClass::member (this=3D0x7fffffffe344) at main.cpp:6 >> 6=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } >> (gdb) continue >> Continuing. >> >> Hardware watchpoint 2: -location this->var >> >> Old value =3D 1 >> New value =3D 2 >> main () at main.cpp:12 >> 12=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return obj.var; >> (gdb) > > ... this indeed is supposed to work. > >> >> In this toy program, watch -l this->var works, but in my large program >> watch -l this->v_ did not. And I do not understand the difference. >> >> > > I'm guessing GDB got confused while trying to grab the address of your > this->v_ expression. If you have a short testcase for that, it would > be great to have this reported (if it isn't already). Thank you for your help. I only have a large testcase for it, but I will try to reduce it to a short testcase. After that, I will open a bug report.