From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7079 invoked by alias); 23 Apr 2013 19:03:44 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 7068 invoked by uid 89); 23 Apr 2013 19:03:44 -0000 X-Spam-SWARE-Status: No, score=-8.9 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 23 Apr 2013 19:03:43 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r3NJ3dhm010823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Apr 2013 15:03:39 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r3NJ3b1d002155; Tue, 23 Apr 2013 15:03:38 -0400 Message-ID: <5176DB09.3090600@redhat.com> Date: Tue, 23 Apr 2013 19:03:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Raphael Zulliger CC: gdb@sourceware.org Subject: Re: Unneeded displaced single stepping causes issues: Performance drop and range stepping killer References: <517516D8.6010604@indel.ch> In-Reply-To: <517516D8.6010604@indel.ch> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-04/txt/msg00066.txt.bz2 On 04/22/2013 11:54 AM, Raphael Zulliger wrote: > According to my current understanding (please correct me if I'm wrong): Range stepping decides whether to send a 'vCont;r' package by comparing the current program counter with the range that needs to be executed (control.step_range_start and control.step_range_end). Using displaced single stepping means that the program counter is, by definition, always outside the range that needs to be single stepped and thus 'range stepping' will never be used. I've been hacking on the range stepping series, and I've actually changed how GDB decides to issue a range-step or not. By "PC-is-in-range" has problems. But, that's largely unrelated. The root issue is the forced displaced step, and that'll remain the same. > What causes the problem? > The following statement (from infrun.c, resume(), git master) decides whether to use displaced single stepping or not: > if (use_displaced_stepping (gdbarch) > && (tp->control.trap_expected > || (step && gdbarch_software_single_step_p (gdbarch))) > && sig == GDB_SIGNAL_0 > && !current_inferior ()->waiting_for_vfork_done) > > According to my experiments: > - Using gdb/gdbserver on x86/64, that statement is 'true' when we step over a breakpoint, but is 'false' otherwise ->range stepping is used when possible > - Using extended remote to ppc603/EABI embedded system, that statement is always 'true' when we step because 'gdbarch_software_single_step_p' returns 'true' ->range stepping is never used > - When patching GDB so that 'gdbarch->software_single_step = NULL', then the behavior is like on x86/64 and thus 'range stepping' works ->range stepping is used when possible > > > Finally, my request: Could someone with more insight into GDB internals please decide whether we have to fix something here and if yes, how? Or, in case that my conclusions are wrong, could you help me to really understand the problem? (FYI: My ultimate goal is to speedup remote debugging for our ppc603/EABI target.) There are several things to consider here. The "(step && gdbarch_software_single_step_p (gdbarch))" part was added because GDB can't currently do multiple software single-steps simultaneously, which is a problem for non-stop mode (which enables displaced stepping). The workaround was to force displaced stepping for all single-steps. GDB knows how to queue displaced step requests (necessary because there's only one scratch pad for all threads), and have threads wait for their turn in the queue. I was working on making GDB aware of multiple software single-steps a while ago, but I got distracted with other things and haven't finished that yet... Then, as you note, gdbarch_software_single_step_p isn't really the right predicate. A better one would be "do I need to software single-step this instruction". There's no such predicate today, because the gdbarch_software_single_step hook is responsible for installing the breakpoints itself, instead of returning a vector of the locations where breakpoints should be set (which I think would be better). -- Pedro Alves