This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: Q: ugdb && watchpoints
- From: Kevin Buettner <kevinb at redhat dot com>
- To: archer at sourceware dot org
- Date: Tue, 19 Oct 2010 15:04:21 -0700
- Subject: Re: Q: ugdb && watchpoints
- References: <20101019181159.GA10275@redhat.com>
On Tue, 19 Oct 2010 20:11:59 +0200
Oleg Nesterov <oleg@redhat.com> wrote:
> I was even thinking about serializing. That is, ugdb schedules only
> one thread to step every time. This way at least we can always know
> who changes the memory. But this is non-trivial, very bad from
> perfomance pov, and doesn't work with syscalls.
I think that stepping one thread at a time is the approach that must
be taken if you want to accurately report the thread that triggered
the watchpoint. (I don't understand the issue with syscalls though...)
> Any advice is very much appreciated. Most probably, there is no any
> clever solution. Once a traced sub-thread detects that a watchpoint
> was changed, it should mark this wp as "reported" for other threads
> and report it to gdb. IOW, we report the random thread and random wp.
Is there a big performance win in implementing software watchpoints in
ugdb? If not, I wouldn't worry about it. My experience with software
watchpoints in native gdb is that they're *very* slow and, as such,
are often not worth using at all.
> Another question. I guess, ugdb should implement hardware watchpoints
> as well? Otherwise, there is no any improvement compared to gdbserver
> in the likely case (at least I think that a-lot-of-wps is not that
> common). But we only have Z2 for both. So I assume that ugdb should
> try to use the hardware watchpoints, but silently fall back to
> emulating?
IMO, hardware watchpoints are definitely worth implementing. From
a user perspective, I would prefer that the stub not implement software
watchpoint support when the real hardware watchpoints are used up.
Hope this helps...
Kevin