This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Fix disarmed hw watchpoints after inferior's fork()
- From: Daniel Jacobowitz <drow at false dot org>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 24 Oct 2007 15:29:37 -0400
- Subject: Re: [patch] Fix disarmed hw watchpoints after inferior's fork()
- References: <20071014155530.GA10094@host0.dyn.jankratochvil.net>
On Sun, Oct 14, 2007 at 05:55:30PM +0200, Jan Kratochvil wrote:
> Hi,
>
> currently on x86_64:
> watch var
> run
> (inferior fork()s a forgotten child)
> (inferior var++) - but it is not noticed by GDB!
>
> i386-nat.c keeps a single mirror of the hardware debug registers but these are
> specific for each LWP and i386-nat.c is also called for multiple INFERIOR_PTIDs
> - such as for the child PID during DETACH_BREAKPOINTS.
You've added a per-process cache of the debug registers. I don't
think we need one; instead we just need to find something halfway
sensible to do when told to remove watchpoints from the child. The
detach_breakpoints / reattach_breakpoints interface is a very ugly
one and this is one of the reasons why.
Maybe we should add a target method, instead, to remove all hardware
breakpoints and watchpoints from a detached process. I'm not sure
what exactly; I know that I've been thinking about this same problem
for remote targets, where I would like to implement follow-fork
eventually.
Hmm, we have target vector inheritance now. The i386 native target
could override the follow-fork implementation and handle removing
hardware watchpoints / breakpoints itself, then delegate to
linux_nat_follow_fork. The generic routines would have to know
whether to handle hardware watchpoints / breakpoints or skip them,
depending on which behavior each target preferred - possibly by
another argument to reattach_breakpoints and detach_breakpoints.
I believe all Linux targets need the same sort of fix, since they all
have some degree of cache now. I do not know what other non-Linux
targets might need. But HP-UX probably needs something special too,
given its page protection watchpoints.
--
Daniel Jacobowitz
CodeSourcery