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

[Pedro Alves <palves at redhat dot com>]

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