Re: Is this a bug in gdb
Volker Weißmann <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
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 [email protected]