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

Andrew Cagney
2002-04-14T21:49:20Z

> 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