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

[Pedro Alves <palves at redhat dot com>]

On 11/30/2012 06:50 PM, Pedro Alves wrote:
> 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).

... and we could add a smoke test to gdb.server/ that did the same
forcing, if it turns out that making the gdbserver peg fit the hole
isn't an ugly/big change.

-- 
Pedro Alves