public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Xin Tong <xerox.time.tech@gmail.com>
To: "Gustavo, Luis" <luis_gustavo@mentor.com>
Cc: gdb@sourceware.org
Subject: Re: Hardware watchpoint for read
Date: Wed, 25 Apr 2012 01:15:00 -0000	[thread overview]
Message-ID: <CALKntY2KhN9x4pdNT0VOYXb-vp3a01DaGQkn-VHcmYGnyoNxrw@mail.gmail.com> (raw)
In-Reply-To: <4F96C2A7.2010206@mentor.com>

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
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>

  reply	other threads:[~2012-04-25  1:15 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-24 13:03 Xin Tong
2012-04-24 13:09 ` Luis Gustavo
2012-04-24 13:16   ` Xin Tong
2012-04-24 13:18     ` Luis Gustavo
2012-04-24 14:18       ` Xin Tong
2012-04-24 14:20         ` Luis Gustavo
2012-04-24 15:06           ` Xin Tong
2012-04-24 15:11             ` Luis Gustavo
2012-04-25  1:15               ` Xin Tong [this message]
2012-04-25 11:51                 ` Luis Gustavo
2012-05-03 19:19                   ` Philippe Waroquiers
2012-05-03 19:41                     ` Xin Tong
2012-05-03 21:18                       ` Philippe Waroquiers

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=CALKntY2KhN9x4pdNT0VOYXb-vp3a01DaGQkn-VHcmYGnyoNxrw@mail.gmail.com \
    --to=xerox.time.tech@gmail.com \
    --cc=gdb@sourceware.org \
    --cc=luis_gustavo@mentor.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).