From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9548 invoked by alias); 3 May 2013 02:32:32 -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 9524 invoked by uid 89); 3 May 2013 02:32:26 -0000 X-Spam-SWARE-Status: No, score=-4.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL autolearn=ham version=3.3.1 Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 03 May 2013 02:32:24 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1UY5nK-0002V8-Hb from Yao_Qi@mentor.com ; Thu, 02 May 2013 19:32:22 -0700 Received: from SVR-ORW-FEM-02.mgc.mentorg.com ([147.34.96.206]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 May 2013 19:32:21 -0700 Received: from qiyao.dyndns.org (147.34.91.1) by svr-orw-fem-02.mgc.mentorg.com (147.34.96.168) with Microsoft SMTP Server id 14.2.247.3; Thu, 2 May 2013 19:32:21 -0700 Message-ID: <518321AC.9060809@codesourcery.com> Date: Fri, 03 May 2013 02:32:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Raphael Zulliger CC: Subject: Re: Unneeded displaced single stepping causes issues: Performance drop and range stepping killer References: <517516D8.6010604@indel.ch> <5177425D.7080901@codesourcery.com> <51778299.40402@indel.ch> In-Reply-To: <51778299.40402@indel.ch> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-SW-Source: 2013-05/txt/msg00015.txt.bz2 On 04/24/2013 02:58 PM, Raphael Zulliger wrote: > 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: > Stop:T05thread:p1.dca318;0:00000002;1:00dce078;2:00dca318;3:00dce09c;4:d8= 434b16;5:005a21b4;6:00dce098;7:00000002;8:00000005;9:000002e4;a:d8434b16;b:= 00dce050;c:00000000;d:f5ffffff;e:00000357;f:f1010000;10:00000000;11:fff7165= 8;12:0068e9f0;13:001dd964;14:00000000;15:00000000;16:0069c3d8;17:00000000;1= 8:00000037;19:00000000;1a:00000032;1b:00e6b4c0;1c:00087e48;1d:00ecd2d0;1e:0= 0ecdb98;1f:00dce078;20:00000003d8434b16;21:3ff199999999999a;22:3ff199999999= 999a;23:0000000000000000;24:0000000000000000;25:0000000000000000;26:0000000= 000000000;27:0000000000000000;28:0000000000000000;29:0000000000000000;2a:00= 00000000000000;2b:0000000000000000;2c:401900a3d70a3d71;2d:3ff199999999999a;= 2e:0000000000000000;2f:0000000000000000;30:0000000000000000;31:000000000000= 0000;32:0000000000000000;33:0000000000000000;34:0000000000000000;35:0000000= 000000000;36:0000000000000000;37:0000000000000000;38:0000000000000000;39:00= 00000000000000;3a:0000000000000000;3b:0000000000000000;3c:0000000000000000;= 3d:0000000000000000;3e:0 000000000000000;3f:0000000000000000;46:efbeadde;40:00049c40;41:0008a030;42:= 20000008;43:00049d58;44:00000000;45:00000000; > Sending packet: $vStopped#55...Packet received: OK > Sending packet: $mdce0c0,40#ec...Packet received: > 00e6b488000020300000a03000dce0d000dce0e8004a066800e6b4c000000202000000010= 0dce0e800dce100004d0aa800dce45000ecd90000b36b7400dce100 > Sending packet: $mdce0c0,40#ec...Packet received: > 00e6b488000020300000a03000dce0d000dce0e8004a066800e6b4c000000202000000010= 0dce0e800dce100004d0aa800dce45000ecd90000b36b7400dce100 > Sending packet: $mdce100,40#ba...Packet received: > 00dce3780008148800ecd9c400000037000000000000003200e6b4c000087e4800dce3580= 0dce35800dce2f800dce154001c748c00dce4008080808064630000 > Sending packet: $mdce340,40#c0...Packet received: > 0000a030000814580000000400dce3500000000000dce35800ecd2d000dce45000dce4000= 0dce36800dce39000ecd2d000ecdb9800dce37800dce390004cbc38 > Sending packet: $mdce380,40#c4...Packet received: > 00ecdb9800dce3ac00dce3a000dce39000dce3f8000830e8ffffffff0000000100dce4500= 0ecdb9801dce3b800ecdb9800ecd9280000000800ecd97000ecd970 > Sending packet: $mdce3c0,40#ef...Packet received: > 00ecdb7000ecd93400ecd97400ecd97000ecdb7000ecd93400e6b6a800dce45000dce4000= 0e6b4c000dce4f40000003500e6b4c000dce3f800dce42800087ec8 > Sending packet: $mdce400,40#bd...Packet received: > 00e6b4c000dce4f40063d47800dce44c00dce4f400dce45000e6b4c000dce44c00e6b4c00= 0dce42800dce4a8000847b000ecce3c00ecd34c00ecd38800000000 > Sending packet: $mdce480,40#c5...Packet received: > 00e6b4c000dce4f4000000350000000000dce4a800377a500000000000000000000000640= 0dce4a800dce4c00008522800dce4d000dce4f40000006400dce4c0 > Sending packet: $mdce4c0,40#f0...Packet received: > 00dce7980007ec586464646464646464005cc40000e6b4c000dce4f06464646400ecc9206= 4646464005c481800dce4f000dce508005ccb0000eccdb800eccdf0 > Sending packet: $mdce780,40#c8...Packet received: > 00dce79800dce6d000dca31800e6b4c00000006400dce79800dce7b00007e89c00dca3180= 0ecc7f80000006400dce7b000dcede80034288400dce99000dce930 > > (Note that this comes from a slightly patched gdb. But I'm pretty sure > theses patches shouldn't have any influence on these memory reads) These memory reads are quite target specific, and I can't see similar=20 pattern on x86. However, I find some duplicated reads on x86 caused by=20 GDB calling 'gdbarch_skip_prologue', which reads several instructions=20 from the remote target. Please try command 'set trust-readonly-sections=20 on'=20 (http://sourceware.org/gdb/current/onlinedocs/gdb/Files.html#index-set-trus= t_002dreadonly_002dsections-1073),=20 by which GDB will fetch instructions from sections instead of the remote=20 target. It helps to reduce the number of rsp packets in traffic. Hope=20 it helps. --=20 Yao (=E9=BD=90=E5=B0=A7)