This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Support targets that know how to step over breakpoints
- From: Hui Zhu <teawater at gmail dot com>
- To: Hui Zhu <hui_zhu at mentor dot com>
- Cc: Pedro Alves <palves at redhat dot com>, lgustavo at codesourcery dot com, gdb-patches at sourceware dot org, Yao Qi <yao at codesourcery dot com>
- Date: Tue, 7 May 2013 10:49:29 +0800
- Subject: Re: [PATCH] Support targets that know how to step over breakpoints
- References: <506D859E dot 9050600 at codesourcery dot com> <507E99BB dot 8050105 at codesourcery dot com> <508FB2B6 dot 6040006 at codesourcery dot com> <50B4DA35 dot 3010206 at codesourcery dot com> <50B4E83D dot 9010507 at redhat dot com> <50B76F6A dot 5060802 at codesourcery dot com> <50B90007 dot 6000802 at redhat dot com> <50B900B3 dot 1010007 at redhat dot com> <512EFE54 dot 4080809 at mentor dot 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.
>>
>