On Tuesday 28 October 2008 14:17:37, Daniel Jacobowitz wrote:
> On Mon, Oct 27, 2008 at 02:19:00PM +0000, Pedro Alves wrote:
> > The attached patch adds a new "StepOverBreakpoints" feature to the
> > remote protocol to the remote stub can tell GDB that the debug api has
> > that feature, and exposes that knowledge to the rest of GDB by
> > adding a new target_ops method (target_can_step_over_breakpoints),
> > and teaching infrun.c to it doesn't need to do the traditional hold-and-step
> > dance (remove breakpoints, single-step, insert breakpoints) from the
> > inferior(s), if the target reports support for stepping over them
> > itself.
> > 
> > Any objections/thoughts on this?
> 
> Does DICOS hit breakpoints at the current PC if you continue, rather
> than step?  I'd hope so - and if so, let's document that expectation.
> It's details like that which confuse people trying to implement the
> remote protocol.

Yeah, thanks for the hint.  It doesn't hit the breakpoint if proceeding
at the PC where the thread stopped (an equivalent to stop_pc on the
GDB side), but will hit it if telling it to resume at some other PC
with a breakpoint there (e.g., jump *PC).  Since GDB normally single-steps
to move past a breakpoint at stop_pc, this hardly matters for DICOS
(other cases where GDB expects to hit a breakpoint at PC happen around
unix signals, but DICOS doesn't have a notion of unix signals).

What I think we should do, is document that the feature only
applies to single-stepping, as attached.

> 
> Does this need to be conditional on the type of breakpoint (hardware
> vs software, Z0 vs memory) or on the actual breakpoint?  For instance,
> platforms with per-thread hardware breakpoints can 'step over'
> hardware breakpoints by temporarily removing them from just one
> thread; and I believe setting IA64_PSR_DD lets you step or continue
> over a breakpoint.
> 

This feature is meant to apply to all breakpoints the stub side
supports.  Although it can be seen as an optimization in
all-stop mode, this is an alternative to displaced stepping
on the GDB side, for non-stop mode --- where we need to make sure
running threads wouldn't miss a breakpoint.
Memory breakpoints are off the chart.  Having a remote stub
support this feature with memory breakpoints on the GDB side
would be too much of a hack.

How about something like this?

@item StepOverBreakpoints
The remote stub knows how to step over breakpoints itself.  If this
feature is supported by the target, then @value{GDBN} does not need to
lift breakpoints off of the inferior to step over them.  This feature
only applies to single-step requests.  @value{GDBN} assumes that the
target hits breakpoints at the current PC if told to continue, rather
than single-step.  This feature is only defined when the remote stub
supports managing breakpoints itself (see @ref{insert breakpoint or
watchpoint packet}).  @value{GDBN} assumes that this feature is
applicable to all breakpoints types supported by the stub.

-- 
Pedro Alves