From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16195 invoked by alias); 25 Jul 2011 14:17:36 -0000 Received: (qmail 16187 invoked by uid 22791); 25 Jul 2011 14:17:34 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-ew0-f41.google.com (HELO mail-ew0-f41.google.com) (209.85.215.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 25 Jul 2011 14:17:16 +0000 Received: by ewy9 with SMTP id 9so2960215ewy.0 for ; Mon, 25 Jul 2011 07:17:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.1.67 with SMTP id 43mr1633543eec.43.1311603434671; Mon, 25 Jul 2011 07:17:14 -0700 (PDT) Received: by 10.14.127.2 with HTTP; Mon, 25 Jul 2011 07:17:14 -0700 (PDT) In-Reply-To: References: <20110715180748.A0390190BC2@elbrus2.mtv.corp.google.com> <20110722164341.GC5177@adacore.com> Date: Mon, 25 Jul 2011 14:42:00 -0000 Message-ID: Subject: Re: [RFC] Make target_read_string faster over high-latency links. From: Daniel Jacobowitz To: Paul Pluzhnikov Cc: Joel Brobecker , Tom Tromey , gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 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/msg00688.txt.bz2 On Fri, Jul 22, 2011 at 12:52 PM, Paul Pluzhnikov wrote: > On Fri, Jul 22, 2011 at 9:43 AM, Joel Brobecker wrote: > >>> Paul> 1. is it ok to read strings 128 bytes at a time, or are there >>> Paul> scenarios (JTAG?) where the latency is low but throughput is also >>> Paul> low (and so reading "unnecessary" data is expensive) ? >>> >>> I don't know, but I assume so. >> >> I think that the risk is to attempt a read that gets past the >> readable memory region. > > That shouldn't be a risk (I think): target_read will (is supposed to) > return partial results. The problem's the other way around; you can't always rely on the target to know what areas of memory not to read. If you read a big chunk of a string off of the stack on uClinux (e.g. auxv or environment), you'll wander up into unmapped memory - and who knows what will happen then! (More recent versions of uClinux manage to catch this in ptrace, thankfully). -- Thanks, Daniel