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

Luis Machado
2012-11-29T14:21:16Z

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