From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7840 invoked by alias); 24 Apr 2013 06:58:45 -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 7828 invoked by uid 89); 24 Apr 2013 06:58:44 -0000 X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received: from ms9.webland.ch (HELO ms9smtp.webland.ch) (92.43.217.109) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 24 Apr 2013 06:58:44 +0000 Received: from ([84.74.172.50]) by ms9smtp.webland.ch (Webland Mail Server v. 10.4.1) with ASMTP id JKE65441; Wed, 24 Apr 2013 08:58:41 +0200 Received: from localhost (localhost [127.0.0.1]) by macserver.private (Postfix) with ESMTP id 1426E17369F2; Wed, 24 Apr 2013 08:58:40 +0200 (CEST) Received: from macserver.private ([127.0.0.1]) by localhost (macserver.private [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcWoD9OHILun; Wed, 24 Apr 2013 08:58:39 +0200 (CEST) Received: from [192.168.1.82] (unknown [192.168.1.82]) by macserver.private (Postfix) with ESMTP id 6352917369E7; Wed, 24 Apr 2013 08:58:38 +0200 (CEST) Message-ID: <51778299.40402@indel.ch> Date: Wed, 24 Apr 2013 06:58:00 -0000 From: Raphael Zulliger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Yao Qi CC: gdb@sourceware.org Subject: Re: Unneeded displaced single stepping causes issues: Performance drop and range stepping killer References: <517516D8.6010604@indel.ch> <5177425D.7080901@codesourcery.com> In-Reply-To: <5177425D.7080901@codesourcery.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-SW-Source: 2013-04/txt/msg00072.txt.bz2 On 04/24/2013 04:24 AM, Yao Qi wrote: > Considering your goal, I suggest that please make range stepping on, > and probably turn displaced stepping off. I'm definitely going to turn range stepping on, as we benefit much from it! Turning off displaced stepping is not an option for our system=20 (multithreaded real-time embedded), as it would mean that other threads could miss=20 breakpoints (which got temporarily removed by the single-stepping mechanism) > If you are using breakpoint > with conditions, please 'set breakpoint condition-evaluation target' > (it requires your remote stub support condition evaluation), it will > improve the performance to some extent. > > On the other hand, we have a local patch to prefer range stepping to > software single step: > > diff --git a/gdb/infrun.c b/gdb/infrun.c > index cbc11f7..b606384 100644 > --- a/gdb/infrun.c > +++ b/gdb/infrun.c > @@ -1824,7 +1824,9 @@ a command like `return' or `jump' to continue execu= tion.")); > } >=20=20=20 > /* Do we need to do it the hard way, w/temp breakpoints? */ > - else if (step) > + else if (step > + && !(target supports range stepping () /* undefined */ > + && THREAD_WITHIN_SINGLE_STEP_RANGE (tp, pc))) > step =3D maybe_software_singlestep (gdbarch, pc); >=20=20=20 > /* Currently, our software single-step implementation leads to differ= ent Unfortunately, this doesn't help. In my use-case in which "unwanted"=20 displaced single-stepping happens, we already took the "if" path of the "else if"=20 you're mentioning here :-(. > > target_supports_range_stepping can be hacked to 1 in your case. It > helps in your case that the remote stub is able to do single step > while the GDB side uses software single step. I don't understand this. (Maybe I already misunderstood the intention of the small patch above?). We use our own gdbstub implementation (completely independent from gdbserver). In order to try the range stepping patches, I already extended our stub to return "vCont;c;C;s;S;t;r" > > My range stepping series didn't include this patch above, because it is a > step-2" patch series. My plan is to draft and post the "step-2" > patches series after getting some comments on range stepping patches. > I'd like to get the existing patches reviewed and committed first, and the > start to work on "step-2" patches. > > B.T.W, we are looking for the opportunities to improve the performance > of remote debugging, "target-side condition evaluation" and > "range stepping" are of this kind. If you know some cases are extremely > slow, please let us know. - "target-side condition evaluation" is certainly something we'd love to have in our system... on the other side, using conditional breakpoints is not the main use case when debugging our system so far. (Probably because we didn't have that feature at all in the past). - There's something I hope we could improve (but I haven't looked into the code yet): When GDB receives a stop reply, it issues many "memory reads". Sometimes it read consecutive memory by multiple RSP packages. Sometime it even reads the same memory region twice. The following shows a typical sequence after 1 single-step (or range step) on our system Sending packet: $vCont;r49c38,49c40:p1.dca318#1f...Packet received: OK Notification received:=20 Stop:T05thread:p1.dca318;0:00000002;1:00dce078;2:00dca318;3:00dce09c;4:d843= 4b16;5:005a21b4;6:00dce098;7:00000002;8:00000005;9:000002e4;a:d8434b16;b:00= dce050;c:00000000;d:f5ffffff;e:00000357;f:f1010000;10:00000000;11:fff71658;= 12:0068e9f0;13:001dd964;14:00000000;15:00000000;16:0069c3d8;17:00000000;18:= 00000037;19:00000000;1a:00000032;1b:00e6b4c0;1c:00087e48;1d:00ecd2d0;1e:00e= cdb98;1f:00dce078;20:00000003d8434b16;21:3ff199999999999a;22:3ff19999999999= 9a;23:0000000000000000;24:0000000000000000;25:0000000000000000;26:000000000= 0000000;27:0000000000000000;28:0000000000000000;29:0000000000000000;2a:0000= 000000000000;2b:0000000000000000;2c:401900a3d70a3d71;2d:3ff199999999999a;2e= :0000000000000000;2f:0000000000000000;30:0000000000000000;31:00000000000000= 00;32:0000000000000000;33:0000000000000000;34:0000000000000000;35:000000000= 0000000;36:0000000000000000;37:0000000000000000;38:0000000000000000;39:0000= 000000000000;3a:0000000000000000;3b:0000000000000000;3c:0000000000000000;3d= :0000000000000000;3e:0000000000000000;3f:0000000000000000;46:efbeadde;40:00= 049c40;41:0008a030;42:20000008;43:00049d58;44:00000000;45:00000000; Sending packet: $vStopped#55...Packet received: OK Sending packet: $mdce0c0,40#ec...Packet received:=20 00e6b488000020300000a03000dce0d000dce0e8004a066800e6b4c0000002020000000100d= ce0e800dce100004d0aa800dce45000ecd90000b36b7400dce100 Sending packet: $mdce0c0,40#ec...Packet received:=20 00e6b488000020300000a03000dce0d000dce0e8004a066800e6b4c0000002020000000100d= ce0e800dce100004d0aa800dce45000ecd90000b36b7400dce100 Sending packet: $mdce100,40#ba...Packet received:=20 00dce3780008148800ecd9c400000037000000000000003200e6b4c000087e4800dce35800d= ce35800dce2f800dce154001c748c00dce4008080808064630000 Sending packet: $mdce340,40#c0...Packet received:=20 0000a030000814580000000400dce3500000000000dce35800ecd2d000dce45000dce40000d= ce36800dce39000ecd2d000ecdb9800dce37800dce390004cbc38 Sending packet: $mdce380,40#c4...Packet received:=20 00ecdb9800dce3ac00dce3a000dce39000dce3f8000830e8ffffffff0000000100dce45000e= cdb9801dce3b800ecdb9800ecd9280000000800ecd97000ecd970 Sending packet: $mdce3c0,40#ef...Packet received:=20 00ecdb7000ecd93400ecd97400ecd97000ecdb7000ecd93400e6b6a800dce45000dce40000e= 6b4c000dce4f40000003500e6b4c000dce3f800dce42800087ec8 Sending packet: $mdce400,40#bd...Packet received:=20 00e6b4c000dce4f40063d47800dce44c00dce4f400dce45000e6b4c000dce44c00e6b4c000d= ce42800dce4a8000847b000ecce3c00ecd34c00ecd38800000000 Sending packet: $mdce480,40#c5...Packet received:=20 00e6b4c000dce4f4000000350000000000dce4a800377a5000000000000000000000006400d= ce4a800dce4c00008522800dce4d000dce4f40000006400dce4c0 Sending packet: $mdce4c0,40#f0...Packet received:=20 00dce7980007ec586464646464646464005cc40000e6b4c000dce4f06464646400ecc920646= 46464005c481800dce4f000dce508005ccb0000eccdb800eccdf0 Sending packet: $mdce780,40#c8...Packet received:=20 00dce79800dce6d000dca31800e6b4c00000006400dce79800dce7b00007e89c00dca31800e= cc7f80000006400dce7b000dcede80034288400dce99000dce930 (Note that this comes from a slightly patched gdb. But I'm pretty sure=20 theses patches shouldn't have any influence on these memory reads) Thanks, Raphael