From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57747 invoked by alias); 18 Feb 2020 01:43:54 -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 57735 invoked by uid 89); 18 Feb 2020 01:43:53 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*MI:sk:d895c95, H*i:sk:d895c95, H*f:sk:d895c95 X-HELO: mail-qt1-f176.google.com Received: from mail-qt1-f176.google.com (HELO mail-qt1-f176.google.com) (209.85.160.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 18 Feb 2020 01:43:51 +0000 Received: by mail-qt1-f176.google.com with SMTP id l21so13420837qtr.8 for ; Mon, 17 Feb 2020 17:43:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=29532kg3TeES6rWP4TU3AMLPVLaZA+4XXBYr9psl/hc=; b=iwQKTX4TyM9jjjPLwQL7yDGIQPVsWDl+reTE9ouyMhw8IbBeVfYcDbHetgh3BC4qE1 OkGpjq0grMLV/18zfiTueMPsT9Mld9Q6sB7PP3mq5bGVW2y0ufwQq5i0nnlBFvNYoWip WvlvtC7P8REfGQdd0WqeewH62w9IxDnyBlXzIwVUmMYBYgU7zlPH/xNKir/oL44ojJQm pzlRDOjSqEWe0+avASkFJRXkJn/TxXHYCLh4CZ/Zb1kbX6jTHu6urZIIJtIx0cdtzZ5Y AQ/8pznMqr9e5882Uh/pGAxQS29OoGYxXnPL3w/Z4qrmQA9td6vQVsS2IYzB7JmcgGug JdxQ== Return-Path: Received: from [192.168.0.185] ([191.34.156.101]) by smtp.gmail.com with ESMTPSA id o19sm1091364qkh.135.2020.02.17.17.43.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Feb 2020 17:43:48 -0800 (PST) Subject: Re: Is this a bug in gdb To: =?UTF-8?Q?Volker_Wei=c3=9fmann?= , 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: Luis Machado Message-ID: Date: Tue, 18 Feb 2020 01:43:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00047.txt.bz2 On 2/17/20 10:34 PM, Volker Weißmann wrote: > > On 2/17/20 3:39 PM, Volker Weißmann wrote: >> >> On 2/17/20 2:50 PM, Luis Machado wrote: >>> On 2/17/20 10:21 AM, Volker Weißmann wrote: >>>> On 2/17/20 1:37 PM, Luis Machado wrote: >>>> >>>>> On 2/16/20 7:40 PM, Volker Weißmann 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  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: >>>>      int var = 0; >>>>      void member() { >>>>          var = 1; >>>>      } >>>> }; >>>> int main() { >>>>      MyClass obj; >>>>      obj.member(); >>>>      obj.var = 2; >>>>      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=0x7fffffffe344) at main.cpp:5 >>>> 5               var = 1; >>>> (gdb) watch -l this->var >>>> Hardware watchpoint 2: -location this->var >>>> (gdb) continue >>>> Continuing. >>>> >>>> Hardware watchpoint 2: -location this->var >>>> >>>> Old value = 0 >>>> New value = 1 >>>> MyClass::member (this=0x7fffffffe344) at main.cpp:6 >>>> 6           } >>>> (gdb) continue >>>> Continuing. >>>> >>>> Hardware watchpoint 2: -location this->var >>>> >>>> Old value = 1 >>>> New value = 2 >>>> main () at main.cpp:12 >>>> 12          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 > > Great. Thanks for that. Our bugzilla is here: https://sourceware.org/bugzilla/ You can open a ticket there. If you can't, let me know and I'll file it.