Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: "Volker Weißmann" <volker.weissmann@gmx.de>
To: gdb@sourceware.org
Subject: Re: Is this a bug in gdb
Date: Tue, 18 Feb 2020 01:35:00 -0000	[thread overview]
Message-ID: <d895c951-e80a-1966-3ac9-ca446de40b83@gmx.de> (raw)
In-Reply-To: <669a79cc-0675-6703-d2e4-687ca8eb863e@gmx.de>


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



  reply	other threads:[~2020-02-18  1:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-16 22:41 Volker Weißmann
2020-02-17 12:37 ` Luis Machado
2020-02-17 13:21   ` Volker Weißmann
2020-02-17 13:50     ` Luis Machado
2020-02-17 14:39       ` Volker Weißmann
2020-02-18  1:35         ` Volker Weißmann [this message]
2020-02-18  1:43           ` Luis Machado

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d895c951-e80a-1966-3ac9-ca446de40b83@gmx.de \
    --to=volker.weissmann@gmx.de \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox