Re: [patch] Fix disarmed hw watchpoints after inferior's fork()

[Daniel Jacobowitz <drow at false dot org>]

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