Re: [PATCH] Support targets that know how to step over breakpoints

[Luis Machado <lgustavo at codesourcery dot com>]

On 11/27/2012 02:20 PM, Pedro Alves wrote:
> On 11/27/2012 03:20 PM, Luis Machado wrote:
>
> > Meanwhile i've updated this patch for the latest cvs head.
> >
> > I'm wondering if the patch is too ugly for someone to take a look at it or if it is too odd a feature to add. I suppose not.
> >
> > Hopefully i can get some traction with this new refreshed and shiny version! :-)
>
> I was hoping others could comment.  :-)
>
> Last we discussed this (probably a years ago already), I expressed my
> concern with upstreaming this as is.  It's that this works by sending a regular
> step command to the target, and then the target steps over any breakpoint that
> may be at the current PC.  If GDB is wanting to move past a breakpoint, this still
> needs to do:
>
>   ->  vCont;s
>   <- T05  (step finished)
>   <- vCont;c

This seems suboptimal, though the outcome is the same.

> An alternative would be to get rid of that T05, by defining new commands that
> tell the target to step-over-breakpoint, or continue-over-breakpoint (and signal
> variants).  E.g., sbc to mean step-break-continue:

If GDB knows the target supports stepping/continuing over breakpoints, 
should we bother with adding new commands at all? Or are we assuming 
"step over" means just single-stepping? In any case, the target can 
probably internally step over such a breakpoint before effectively 
continuing in response to a vCont;c packet. What do you think?

We would then get rid of both the vCont;s and the T05 response.

>   ->  vCont;spc
>
> That'd move past the breakpoint without causing a stop immediately.
>
> Guess I need to convince myself the current design is good enough.  Comments?

Though suboptimal, the design seems to do the job without being ugly. 
That said, the vCont;c case could be addressed for a cleaner feature.

But i think new commands are a little too much.

Testing this is also a problem i'm worried about. We can't reliably test 
this (and other) features that are not properly supported by gdbserver, 
but i suppose this is a different discussion.

Luis