Re: Hardware watchpoint for read

[Luis Gustavo <luis_gustavo@mentor.com>]

On 04/24/2012 10:15 PM, Xin Tong wrote:
> On Tue, Apr 24, 2012 at 11:11 AM, Luis Gustavo<luis_gustavo@mentor.com>  wrote:
>> On 04/24/2012 12:06 PM, Xin Tong wrote:
>>>
>>> On Tue, Apr 24, 2012 at 10:19 AM, Luis Gustavo<luis_gustavo@mentor.com>
>>>   wrote:
>>>>
>>>> On 04/24/2012 11:17 AM, Xin Tong wrote:
>>>>>
>>>>>
>>>>> On Tue, Apr 24, 2012 at 9:18 AM, Luis Gustavo<luis_gustavo@mentor.com>
>>>>>   wrote:
>>>>>>
>>>>>>
>>>>>> On 04/24/2012 10:15 AM, Xin Tong wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Apr 24, 2012 at 9:09 AM, Luis Gustavo<luis_gustavo@mentor.com>
>>>>>>>   wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>
>>>>>>>> On 04/24/2012 10:02 AM, Xin Tong wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hello
>>>>>>>>>
>>>>>>>>> I am wondering that can gdb insert hardware watch point for read to
>>>>>>>>> the watched memory ? can other debugger do that ? is it supported in
>>>>>>>>> hardware watchpoint ?
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>> Xin
>>>>>>>>>
>>>>>>>>
>>>>>>>> Read watchpoints are hard to implement as soft-watchpoints, so
>>>>>>>> they're
>>>>>>>> usually implemented as hardware watchpoints.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> software write watchpoint is easier to implement ? do not software
>>>>>>> watchpoint need to watch all memory accesses (read and write) to a
>>>>>>> memory location in software ?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Writes are "easier" to implemenet due to the fact that they usually
>>>>>> change
>>>>>> memory contents. Reads don't.
>>>>>
>>>>>
>>>>>
>>>>> Either way, do not gdb need to instrument every memory accesses if a
>>>>> software watch point is used ?
>>>>
>>>>
>>>>
>>>> It does things lazily. It single-steps instruction-by-instruction and
>>>> checks
>>>> for change of contents.
>>>
>>>
>>> ok, i see. so it  does not dissasmble the instructions.  but for read,
>>> it may need to disassemble the instructions which makes it harder to
>>> implement.
>>
>>
>> Yes, this is the problem with read watchpoints implemented as software
>> watchpoints. It's hard to determine a trigger without making it painfully
>> slow, and the debugger needs knowledge about the arch's instructions.
>>
>>
>>>>
>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> If a debugger knows how to properly set the bits in the hardware,
>>>>>>>> either
>>>>>>>> through ptrace or other means, it can configure a
>>>>>>>> read/write/read-write
>>>>>>>> watchpoint. Depends on hardware support really.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> do you know whether this is supported on the x86 chips ? is thee a way
>>>>>>> to try this out in gdb ?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> All those modes should be supported in x86. Try "watch", "rwatch" and
>>>>>> "awatch".
>>>>>
>>>>>
>>>>>
>>>>> how are hardware watch,  rwatch and awatch implemented in gdb. make
>>>>> call to ptrace apis and ptrace apis  program some x86 registers
>>>>> through a driver interfaces ?
>>>>>
>>>>
>>>> ptrace calls really. GDB's x86 backend knows how to set those bits.
>
> what are the performance penalties of having a watchpoint on a memory
> location in the state of the art x86 processor. Because it might be
> implemented with a parallel circuitry in the processor, my guess is
> that it could be cheap.

Do you mean a hardware watchpoint? It's hard to say for sure without 
looking at the processors inner workings, but the penalty is probably 
very small.

When the conditions are satisfied, a TRAP will be generated and it will 
get through to the debugger via the kernel.

Suppose we issue a continue command... For the debugger, the inferior 
will run uninterrupted while the hardware watchpoint is active.

This is not the case with software watchpoints, as the debugger will be 
constantly touching the inferior while it runs.

>
> Xin
>
>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Luis
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>