This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Hardware watchpoint for read


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.

Xin

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]