Re: Is this a bug in gdb

[Luis Machado <luis.machado@linaro.org>]

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.