From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16230 invoked by alias); 7 May 2013 02:50:15 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 16211 invoked by uid 89); 7 May 2013 02:50:12 -0000 X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,SPF_PASS autolearn=ham version=3.3.1 Received: from mail-ob0-f176.google.com (HELO mail-ob0-f176.google.com) (209.85.214.176) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 07 May 2013 02:50:11 +0000 Received: by mail-ob0-f176.google.com with SMTP id wc20so69119obb.35 for ; Mon, 06 May 2013 19:50:09 -0700 (PDT) X-Received: by 10.182.105.7 with SMTP id gi7mr43178obb.10.1367895009726; Mon, 06 May 2013 19:50:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.13.133 with HTTP; Mon, 6 May 2013 19:49:29 -0700 (PDT) In-Reply-To: <512EFE54.4080809@mentor.com> References: <506D859E.9050600@codesourcery.com> <507E99BB.8050105@codesourcery.com> <508FB2B6.6040006@codesourcery.com> <50B4DA35.3010206@codesourcery.com> <50B4E83D.9010507@redhat.com> <50B76F6A.5060802@codesourcery.com> <50B90007.6000802@redhat.com> <50B900B3.1010007@redhat.com> <512EFE54.4080809@mentor.com> From: Hui Zhu Date: Tue, 07 May 2013 02:50:00 -0000 Message-ID: Subject: Re: [PATCH] Support targets that know how to step over breakpoints To: Hui Zhu Cc: Pedro Alves , lgustavo@codesourcery.com, gdb-patches@sourceware.org, Yao Qi Content-Type: text/plain; charset=ISO-8859-1 X-SW-Source: 2013-05/txt/msg00167.txt.bz2 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 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. >> >