From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7800 invoked by alias); 22 Apr 2013 10:54:28 -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 7789 invoked by uid 89); 22 Apr 2013 10:54:28 -0000 X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_20,KHOP_RCVD_UNTRUST,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; Mon, 22 Apr 2013 10:54:27 +0000 Received: from ([84.74.172.50]) by ms9smtp.webland.ch (Webland Mail Server v. 10.4.1) with ASMTP id HOY70822 for ; Mon, 22 Apr 2013 12:54:22 +0200 Received: from localhost (localhost [127.0.0.1]) by macserver.private (Postfix) with ESMTP id 8AF17172ECC7; Mon, 22 Apr 2013 12:54:20 +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 Fkz7tLDERoZz; Mon, 22 Apr 2013 12:54:19 +0200 (CEST) Received: from [192.168.1.82] (unknown [192.168.1.82]) by macserver.private (Postfix) with ESMTP id 3CE63172ECBB for ; Mon, 22 Apr 2013 12:54:18 +0200 (CEST) Message-ID: <517516D8.6010604@indel.ch> Date: Mon, 22 Apr 2013 10:54: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: gdb@sourceware.org Subject: Unneeded displaced single stepping causes issues: Performance drop and range stepping killer Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-SW-Source: 2013-04/txt/msg00058.txt.bz2 Hi I've been playing around with the 'range stepping' patch set. (Thanks=20 for that great feature!) Thereby I encountered the following behavior: Targets, having a 'gdbarch->software_single_step' function set, are=20 always using displaced single stepping even when "normal" single=20 stepping would be sufficient. (sure, displaced single-stepping may have=20 the advantage of less breakpoint hits by foreign task, but...) While this is not a problem as such, it may be sub-optimal because: Issue a) At least on extended-remote ppc target displaced single=20 stepping causes much more RSP traffic Issue b) It renders 'range stepping' useless Let me explain Issue a) Not sure whether this statement is correct for all platform out there,=20 but on my PPC603/EABI extended remote target, the difference between=20 non- vs. displaced single stepping is quite big. (gdb) set displaced-stepping 0 (gdb) si Sending packet: $m832d0,4#fe...Packet received: 9421ffc8 Sending packet: $vCont;s:p1.dca118#83...Packet received: OK Notification received: Stop:T05thread:p1.dca118;0:00dcdea0;1:00dcde40;2:00dca118;3:00dcdea4;4:00dc= dea0;5:00000142;6:00dcde68;7:00000002;8:00000005;9:00dcdea4;a:00579e90;b:00= ed4b34;c:00000000;d:f7ffffff;e:00000357;f:f1010000;10:00000000;11:fff71658;= 12:0068e738;13:001dd964;14:00000000;15:00000000;16:0069c120;17:00000000;18:= 00000037;19:00000000;1a:00000032;1b:00e6b2c0;1c:00087e48;1d:00ed12a0;1e:00e= d1b68;1f:00dcde78;20:00000006347fd013;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= 0832d4;41:0008a030;42:20000004;43:00049cd0;44:00000000;45:00000000; Sending packet: $vStopped#55...Packet received: OK 0x000832d4 20 SourceLine::SourceLine( const std::string=20 &fileName, versus: (gdb) set displaced-stepping 1 (gdb) si Sending packet: $m1508,4#9b...Packet received: 3c000058 Sending packet: $m832d4,4#02...Packet received: 7c0802a6 Sending packet: $X1508,0:#bc...Packet received: binary downloading NOT supported by target Sending packet: $M1508,4:7c0802a6#b0...Packet received: OK Sending packet: $g#67...Packet received:=20 00dcdea000dcde4000dca11800dcdea400dcdea00000014200dcde68000000020000000500d= cdea400579e9000ed4b3400000000f7ffffff00000357f101000000000000fff716580068e7= 38001dd96400000000000000000069c1200000000000000037000000000000003200e6b2c00= 0087e4800ed12a000ed1b6800dcde7800000006347fd0133ff199999999999a3ff199999999= 999a00000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000040= 1900a3d70a3d713ff199999999999a000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000832d40008a0302000000400049cd00000000000000000efbeadde Sending packet: $P40=3D00001508#7f...Packet received: OK Packet P (set-register) is supported Sending packet: $vCont;s:p1.dca118#83...Packet received: OK Notification received:=20 Stop:T05thread:p1.dca118;0:00049cd0;1:00dcde40;2:00dca118;3:00dcdea4;4:00dc= dea0;5:00000142;6:00dcde68;7:00000002;8:00000005;9:00dcdea4;a:00579e90;b:00= ed4b34;c:00000000;d:f7ffffff;e:00000357;f:f1010000;10:00000000;11:fff71658;= 12:0068e738;13:001dd964;14:00000000;15:00000000;16:0069c120;17:00000000;18:= 00000037;19:00000000;1a:00000032;1b:00e6b2c0;1c:00087e48;1d:00ed12a0;1e:00e= d1b68;1f:00dcde78;20:00000006347fd013;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= 00150c;41:0008a030;42:20000004;43:00049cd0;44:00000000;45:00000000; Sending packet: $vStopped#55...Packet received: OK Sending packet: $M1508,4:3c000058#78...Packet received: OK Sending packet: $P40=3D000832d8#ba...Packet received: OK 0x000832d8 20 SourceLine::SourceLine( const std::string=20 &fileName, (gdb) Issue b) According to my current understanding (please correct me if I'm wrong):=20 Range stepping decides whether to send a 'vCont;r' package by comparing=20 the current program counter with the range that needs to be executed=20 (control.step_range_start and control.step_range_end). Using displaced=20 single stepping means that the program counter is, by definition, always=20 outside the range that needs to be single stepped and thus 'range=20 stepping' will never be used. What causes the problem? The following statement (from infrun.c, resume(), git master) decides=20 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 =3D=3D 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=20 step over a breakpoint, but is 'false' otherwise ->range stepping is=20 used when possible - Using extended remote to ppc603/EABI embedded system, that=20 statement is always 'true' when we step because=20 'gdbarch_software_single_step_p' returns 'true' ->range stepping is=20 never used - When patching GDB so that 'gdbarch->software_single_step =3D NULL',= =20 then the behavior is like on x86/64 and thus 'range stepping' works=20 ->range stepping is used when possible Finally, my request: Could someone with more insight into GDB internals=20 please decide whether we have to fix something here and if yes, how? Or,=20 in case that my conclusions are wrong, could you help me to really=20 understand the problem? (FYI: My ultimate goal is to speedup remote=20 debugging for our ppc603/EABI target.) Thanks, Raphael