This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Hardware watchpoint for read
- From: "Philippe Waroquiers" <philippe dot waroquiers at skynet dot be>
- To: "Gustavo, Luis" <luis_gustavo at mentor dot com>, "Xin Tong" <xerox dot time dot tech at gmail dot com>
- Cc: <gdb at sourceware dot org>
- Date: Thu, 3 May 2012 21:19:40 +0200
- Subject: Re: Hardware watchpoint for read
- References: <CALKntY3aH8amKnr9kZFBKQZEawvFzADiDo+t9Yj_gcx4Qy-kXQ@mail.gmail.com> <4F96A614.3040303@mentor.com> <CALKntY2EC1CUsO=Eavfh23WtQFsJCt8ANEhddL9Deeuyiw+iug@mail.gmail.com> <4F96A812.4000008@mentor.com> <CALKntY0TGK7YK+Ns5ck6B7=aVd9pSz4T__qe8BYjDRL9S3aR2g@mail.gmail.com> <4F96B68C.3050703@mentor.com> <CALKntY0MN4hp8QE6h2EAdmWFB6SivcrXMMnxsZ_sdJaS9u4yeA@mail.gmail.com> <4F96C2A7.2010206@mentor.com> <CALKntY2KhN9x4pdNT0VOYXb-vp3a01DaGQkn-VHcmYGnyoNxrw@mail.gmail.com> <4F97E547.4070307@mentor.com>
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.
Which makes software watchpoints extremely slow, while hardware
watchpoints have limitations (e.g. in nr or size).
Note that the Valgrind gdbserver (in 3.7.0) provides "unlimited simulated
hw watchpoints" : these are slower than real hw watchpoints, but "only"
suffer from the Valgrind slowdown.
Philippe