From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25444 invoked by alias); 15 Jul 2011 18:08:09 -0000 Received: (qmail 25432 invoked by uid 22791); 15 Jul 2011 18:08:08 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (74.125.121.67) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 15 Jul 2011 18:07:52 +0000 Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id p6FI7oJQ005503 for ; Fri, 15 Jul 2011 11:07:50 -0700 Received: from elbrus2.mtv.corp.google.com (elbrus2.mtv.corp.google.com [172.18.111.111]) by wpaz13.hot.corp.google.com with ESMTP id p6FI7mHP021738; Fri, 15 Jul 2011 11:07:49 -0700 Received: by elbrus2.mtv.corp.google.com (Postfix, from userid 74925) id A0390190BC2; Fri, 15 Jul 2011 11:07:48 -0700 (PDT) To: gdb-patches@sourceware.org Cc: ppluzhnikov@google.com Subject: [RFC] Make target_read_string faster over high-latency links. Message-Id: <20110715180748.A0390190BC2@elbrus2.mtv.corp.google.com> Date: Fri, 15 Jul 2011 18:09:00 -0000 From: ppluzhnikov@google.com (Paul Pluzhnikov) X-IsSubscribed: yes 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 X-SW-Source: 2011-07/txt/msg00393.txt.bz2 Greetings, Here at Google we sometimes debug binaries running in production data centers via remote gdbserver. When GDB is running in Mountain View, California and the gdbserver is running in Taiwan, the speed-of-light fiber round trip delay is approximately 110ms, and the actual ping time I see is slightly better than 200ms. Unfortunately (for us), GDB is not tuned for such high-latency links. In particular, I see the following timestamped packet traces: ... 00:00:25 Sending packet: $m2b6b7958a7b8,28#3e...Packet received: 00c078796b2b000090a758796b2b0000f85d99796b2b000000509c796b2b0000d8b678796b2b0000 00:00:25 Sending packet: $m2b6b7958a790,4#d7...Packet received: 2f757372 00:00:25 Sending packet: $m2b6b7958a794,4#db...Packet received: 2f677274 00:00:26 Sending packet: $m2b6b7958a798,4#df...Packet received: 652f7632 00:00:26 Sending packet: $m2b6b7958a79c,4#0a...Packet received: 2f6c6962 00:00:26 Sending packet: $m2b6b7958a7a0,4#ff...Packet received: 36342f6c 00:00:26 Sending packet: $m2b6b7958a7a4,4#03...Packet received: 69626372 00:00:26 Sending packet: $m2b6b7958a7a8,4#07...Packet received: 7970742e 00:00:26 Sending packet: $m2b6b7958a7ac,4#32...Packet received: 736f2e31 00:00:27 Sending packet: $m2b6b7958a7b0,4#00...Packet received: 00000000 00:00:27 Sending packet: $m2b6b799c5000,28#00...Packet received: 00609c796b2b000078ac58796b2b0000a08dbc796b2b0000e0549c796b2b0000b8a758796b2b0000 00:00:27 Sending packet: $m2b6b7958ac78,4#09...Packet received: 2f757372 00:00:27 Sending packet: $m2b6b7958ac7c,4#34...Packet received: 2f677274 00:00:27 Sending packet: $m2b6b7958ac80,4#02...Packet received: 652f7632 00:00:27 Sending packet: $m2b6b7958ac84,4#06...Packet received: 2f6c6962 00:00:28 Sending packet: $m2b6b7958ac88,4#0a...Packet received: 36342f6c 00:00:28 Sending packet: $m2b6b7958ac8c,4#35...Packet received: 6962646c 00:00:28 Sending packet: $m2b6b7958ac90,4#03...Packet received: 2e736f2e 00:00:28 Sending packet: $m2b6b7958ac94,4#07...Packet received: 32000000 ... This is GDB walking through the shared library list, and reading shared library names from gdbserver via target_read_string 4 bytes at a time ;-( It takes approximately 15s to read 10 (relatively short) pathnames, and this is repeated twice, for a total of 30s, which is about 1/3 of the total time it takes to attach the remote process. I have a patch that changes minimum size to read in target_read_string() to MIN(len, 128), and with that patch I can save quite a few round trips: ... 00:00:29 Sending packet: $m2b6b7958a7b8,28#3e...Packet received: 00c078796b2b000090a758796b2b0000f85d99796b2b000000509c796b2b0000d8b678796b2b0000 00:00:29 Sending packet: $m2b6b7958a790,80#0b...Packet received: 2f7573722f677274652f76322f6c696236342f6c696263727970742e736f2e31000000000000000000c078796b2b000090a758796b2b0000f85d99796b2b000000509c796b2b0000d8b678796b2b0000b8a758796b2b0000000000000000000028ac58796b2b00000000000000000000f85d99796b2b0000a85e99796b2b0000 00:00:29 Sending packet: $m2b6b799c5000,28#00...Packet received: 00609c796b2b000078ac58796b2b0000a08dbc796b2b0000e0549c796b2b0000b8a758796b2b0000 00:00:29 Sending packet: $m2b6b7958ac78,80#3d...Packet received: 2f7573722f677274652f76322f6c696236342f6c6962646c2e736f2e32000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00:00:30 Sending packet: $m2b6b799c54e0,28#39...Packet received: 00a0bc796b2b0000b8549c796b2b0000881dde796b2b0000c0599c796b2b000000509c796b2b0000 00:00:30 Sending packet: $m2b6b799c54b8,80#3c...Packet received: 2f7573722f677274652f76322f6c696236342f6c6962707468726561642e736f2e3000000000000000a0bc796b2b0000b8549c796b2b0000881dde796b2b0000c0599c796b2b000000509c796b2b0000e0549c796b2b0000000000000000000050599c796b2b00000000000000000000981dde796b2b0000481ede796b2b0000 ... Questions: 1. is it ok to read strings 128 bytes at a time, or are there scenarios (JTAG?) where the latency is low but throughput is also low (and so reading "unnecessary" data is expensive) ? 1a. If yes, would it be acceptable to make this size a runtime-configurable parameter? 2. Current target_read_string aligns reads on a 4-byte boundary. Code could be simplified quite a bit if it didn't do that. Are there targets where such alignment is required? Thanks, -- Paul Pluzhnikov