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

[Hui Zhu]

Hello guys,

I am just working on this function.
Now, I named the function to "continue_over_breakpoints".
As its name, when GDB got a breakpoint that it want to pass it, just use "continue_over_breakpoints" replace "continue".

->  vCont;cob

There are 2 parts that I hope to get morecomments:
1. When the gdb want remote target use "continue_over_breakpoints", there need some update in to_resume.
If add new flags to to_resume, it will make a lot of functions of xxx_resume  update.
So what I thought is what about let step to -1 when GDB want "continue_over_breakpoints"?
Or just add a new to_continue_over_breakpoints interface?

2. About the test, my understand about Pedro's comments is: force GDB use "continue_over_breakpoints" with "set remote xxx on".  And add new option to gdbserver let it open support to "continue_over_breakpoints".  Then we can test it.
My understandis right?

Please help me with them.

Thanks,
Hui

On 12/01/12 02:53, Pedro Alves wrote:
> 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.
>