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

Pedro Alves
2012-11-30T18:50:59Z

On 11/29/2012 02:21 PM, Luis Machado wrote:
> 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 have cases where we want to vCont;c with a breakpoint at PC, and really
hit it. That's how "jump" works, but we have other cases in
handle_inferior_event that rely on that too (signal handler related things).

> 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.

I suppose the current proposal isn't that much of a burden to support
and I could well live with it.

> 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.

Actually, nowadays x86 GNU/Linux gdbserver is able to step ever
breakpoints. See linux-low.c:linux_resume. But we don't want to
use that support for regular breakpoints, because it's implemented
by the old stop everything/remove break / step/put breakpoint back / resume
dance, and displaced stepping is better. So we could hack it into
the semantics of this qSupported feature, and run the whole
testsuite with that forced enabled (e.g., with a "set remote foo" command
in a board file).

--
Pedro Alves