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

[Hui Zhu <teawater@gmail.com>]

Hi guys,

I post some patches for this issue.
You can find them in:
http://sourceware.org/ml/gdb-patches/2013-03/msg00054.html
http://sourceware.org/ml/gdb-patches/2013-03/msg00055.html
http://sourceware.org/ml/gdb-patches/2013-03/msg00065.html
http://sourceware.org/ml/gdb-patches/2013-03/msg00066.html

Thanks,
Hui

On Thu, Feb 28, 2013 at 2:51 PM, Hui Zhu <hui_zhu@mentor.com> wrote:
> 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.
>>
>