From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30101 invoked by alias); 17 Feb 2020 13:50:09 -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 30088 invoked by uid 89); 17 Feb 2020 13:50:09 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*f:sk:a600eca, H*i:sk:a600eca, H*MI:sk:a600eca X-HELO: mail-qk1-f172.google.com Received: from mail-qk1-f172.google.com (HELO mail-qk1-f172.google.com) (209.85.222.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Feb 2020 13:50:07 +0000 Received: by mail-qk1-f172.google.com with SMTP id u124so15688476qkh.13 for ; Mon, 17 Feb 2020 05:50:07 -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=WpCV999EnoKQoUy831ie4nfyqZcSDeOQMSY1EgQJScU=; b=vjERXMf5skm8dAE+Sm4hj1Wqqv4Va+s+PPYfzfRUv2CtMDHNkYFgpLXcZQN5h8EZMN aKRoDq7wAG9RaHcqo0Cy1Z7hPZ4iJqvAVwkSuR0N5Hs6jAQiKRUtY+rKLTNk/VVCMRsK Al2/cOISez2VENc7VQNEkxU6mpTvKTSmIiAJc6KZwM8huS4MNcdsQ3SNPFQHV1yoxB8F 5aaZStOau6kS4X66Kb7l+kCp9h+xy1mxcCZdWAnXfUQzF8INcF+ZJsEKvqwCPmnmkVDt UUhOAbDig55mCtXPz6QyZwCITPFRlX5NV+2FHXR5M+T5w2WDujIXNBgEyGWXW29Sg0vB k5MA== Return-Path: Received: from [192.168.0.185] ([191.34.156.101]) by smtp.gmail.com with ESMTPSA id a196sm229782qkg.105.2020.02.17.05.50.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Feb 2020 05:50:04 -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> From: Luis Machado Message-ID: <92c83e9f-dff3-eb53-183d-46d495db0d51@linaro.org> Date: Mon, 17 Feb 2020 13:50: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/msg00041.txt.bz2 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).