Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: "Philippe Waroquiers" <philippe.waroquiers@skynet.be>
To: "Jan Kratochvil" <jan.kratochvil@redhat.com>,
	"robert song" <robertsong.japan@gmail.com>
Cc: <gdb@sourceware.org>,	"Julian Seward" <jseward@acm.org>
Subject: Re: Why no hwatch command in gdb ?
Date: Thu, 10 Mar 2011 14:47:00 -0000	[thread overview]
Message-ID: <FD8E0CA1171A4A4AAD80B5E5C0747567@soleil> (raw)
In-Reply-To: <20110310134453.GA11068@host1.jankratochvil.net>

On the side of 'hardware' watchpoints limitations:
I am busy embedding a gdbserver inside Valgrind (target is
to integrate it in April, but more review activity is still needed).

As part of this work, unlimited "simulated hardware watchpoints"
have been implemented on top of the "address access/validity bits"
of Valgrind memcheck tool.

These simulated hardware watchpoints are of course a lot
slower than real hardware watchpoint, but they are faster
than gdb "single stepping" watchpoints (and more over,
you have unlimited "read watchpoints").

I only encountered a small problem with gdb "remote":
There is a gdb command to configure the nr of remote hardware watchpoint
but there is no command to configure the length for an hardware
watchpoint: e.g. for i386, gdb remote "hardcodes" the length to 4 bytes
(which looks wrong btw, as the real hw can go up to 8 bytes I believe).

So, I have in a corner a patch implementing
   'set remote hardware-watchpoint-length-limit'
to configure the max length limit of an hw watchpoint.

With this patch + Valgrind gdbserver, you can e.g. read or write or access
watch many and/or big memory ranges, paying "only" the "limited"
Valgrind memcheck overhead (still big overhead, but significantly
faster than pure gdb software watchpoint).

I believe it would be nice to add this new command in gdb.

If you want more info about the gdbserver in Valgrind, I can give more
(I expect to output a new improved beta version of the Valgrind gdbserver
patch in the coming days).

Philippe


  reply	other threads:[~2011-03-10 14:47 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-10  7:25 robert song
2011-03-10  8:12 ` Jan Kratochvil
2011-03-10 10:09   ` robert song
2011-03-10 10:34     ` Jan Kratochvil
2011-03-10 11:26       ` Eli Zaretskii
2011-03-10 11:34         ` Joel Brobecker
2011-03-10 12:27           ` Pedro Alves
2011-03-10 11:55         ` Jan Kratochvil
2011-03-10 14:47           ` Frank Ch. Eigler
2011-03-10 12:18       ` robert song
2011-03-10 13:45         ` Jan Kratochvil
2011-03-10 14:47           ` Philippe Waroquiers [this message]
2011-03-10 21:04             ` Tom Tromey
2011-03-11  7:58               ` Philippe Waroquiers
2011-03-11 17:48           ` Daniel Jacobowitz
2011-03-10  8:23 paawan oza

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=FD8E0CA1171A4A4AAD80B5E5C0747567@soleil \
    --to=philippe.waroquiers@skynet.be \
    --cc=gdb@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    --cc=jseward@acm.org \
    --cc=robertsong.japan@gmail.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