Re: Display of read/access watchpoints when HAVE_NONSTEPPABLE_WATCHPOINT

[Daniel Jacobowitz <drow@false.org>]

On Thu, May 06, 2004 at 08:59:06PM +0200, Eli Zaretskii wrote:
> > Date: Thu, 6 May 2004 10:21:46 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > > 
> > > Thus, for the STOPPED_BY_WATCHPOINT trick to work, bpstat_stop_status
> > > needs to have access to the relevant parts of the inferior's struct
> > > execution_control_state variable.  It doesn't seem to me too hard to
> > > pass that as an additional argument.
> > 
> > This is the point where I want to go back to the "design" bit that Mark
> > was talking about.
> 
> Redesigning watchpoint handling doesn't mean we should abandon fixing
> bugs in the meantime, IMHO.
> 
> > execution_control_state is private to infrun.c, and
> > I would prefer to leave it that way; the more localized it is, the
> > easier it is to clean up and maintain, without having to rip tentacles
> > out of other parts of GDB.
> 
> Sorry, I don't understand: bpstat_stop_status is called by infrun, so
> passing it execution_control_state doesn't violate its being private
> to infrun.c.

I don't understand your logic.  Right now, the type "struct
execution_control_state" is private to the file "infrun.c", which is
the execution state machine.

The function "bpstat_stop_status" is in the file "breakpoint.c", which
is the bulk of GDB's breakpoint management code.

I'm saying that I don't think exposing the internals of the execution
state machine to the separate module responsible for breakpoints, even
to a function only used by the execution state machine, is a good idea.
If two interfaces of STOPPED_BY_WATCHPOINT need access to something
from ecs, then pass it independently, or come up with a better-defined
interface.

-- 
Daniel Jacobowitz