From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47137 invoked by alias); 18 Feb 2020 01:35:04 -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 47124 invoked by uid 89); 18 Feb 2020 01:35:03 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 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:669a79c, H*i:sk:669a79c, H*MI:sk:669a79c X-HELO: mout.gmx.net Received: from mout.gmx.net (HELO mout.gmx.net) (212.227.15.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 18 Feb 2020 01:35:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1581989696; bh=p7pzJe9V23QUiCz13pQ3dgAN6vEdBKhtE4A+LFnaP4M=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=hHb92y6ifbAdUCIR3L6byKnRmkkPKTB8Gaz7hi8c6PUirhLJmBC6XGEE6pRIkw4YH MCzLLHo9b2poTjqIPVXg+aJZApMeJJ62Gk6Y4cq4/DNHCx73+cKBfvFsO42uqS4GdE OKO2ncyuAqUFEi/jpzraQvKsExzXNkFdd+s65v5c= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.64] ([46.223.148.137]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MtfJd-1jJjNn0NQd-00v4f6 for ; Tue, 18 Feb 2020 02:34:56 +0100 Subject: Re: Is this a bug in gdb To: 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> <669a79cc-0675-6703-d2e4-687ca8eb863e@gmx.de> From: =?UTF-8?Q?Volker_Wei=c3=9fmann?= Message-ID: Date: Tue, 18 Feb 2020 01:35: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: <669a79cc-0675-6703-d2e4-687ca8eb863e@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00046.txt.bz2 On 2/17/20 3:39 PM, Volker Wei=C3=9Fmann wrote: > > 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. I managed to find a simple testcase: Turns out that gdb cannot watch -location a restrict pointer. I wrote to bug-gdb@gnu.org