Re: [RFA] Fix watchpoints when stepping over a breakpoint

[Andrew Cagney <ac131313 at cygnus dot com>]

> Date: Sun, 07 Apr 2002 12:16:22 -0400
>> From: Andrew Cagney <ac131313@cygnus.com>
>> 
>> What would it take to replace DECR_PC_AFTER_BREAK with a read_pc() 
>> function that determines the stop address from the i386 hardware 
>> registers and other state information?

Tried it (yes i386).  It is more complicated (suprise) than I thought. 
As far as I can tell, the i386 backend can't locally differentiate 
between a single step trap or a breakpoint trap.  Instead it needs to 
refer to GDB's internal state to figure out what it was probably trying 
to do.

> How would that help to solve this specific problem?  The original
> problem happened on i386 as well, right?  So at best, you'd be pushing
> the ``rat's nest'' from GDB application level to x86-specific parts of
> GDB, where there still will be need to decide what kind of breakpoint
> to reports to the application level.
> 
> Or am I missing something?
> 
> In general, it strikes me that breakpoint.c's design goes against what
> you propose: it defines an API where GDB queries the target about the
> status of all the known break/watchpoints, and then decides what
> happened based on what the target reports.  You seem to suggest a
> different strategy: let the target tell GDB what happened.  While
> certainly a viable idea, it sounds like a major redesign of a central
> GDB facility, no?

No that would remain.  I'm just looking at the read_pc() / 
DECR_PC_AFTER_BREAK pair.  In bpstat_stop_status(), for instance, there 
is a call to get_current_frame() that creates a frame with the wrong PC 
value :-(

Andrew