From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9328 invoked by alias); 20 Jul 2011 17:10:44 -0000 Received: (qmail 9312 invoked by uid 22791); 20 Jul 2011 17:10:43 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 20 Jul 2011 17:09:59 +0000 Received: (qmail 21804 invoked from network); 20 Jul 2011 17:09:59 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 20 Jul 2011 17:09:59 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFC][patch] Avoid repeated calls to solib_add on initial attach. Date: Wed, 20 Jul 2011 17:36:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic; KDE/4.6.2; x86_64; ; ) Cc: Paul Pluzhnikov , Luis Machado References: <20110715205209.8B3B3190BC2@elbrus2.mtv.corp.google.com> <201107201735.13150.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107201809.56890.pedro@codesourcery.com> 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/msg00553.txt.bz2 On Wednesday 20 July 2011 17:44:43, Paul Pluzhnikov wrote: > On Wed, Jul 20, 2011 at 9:35 AM, Pedro Alves wrote: > > >> qStr {addr},{maxlen},{terminator} > ... > > We considered a packet like this too, but decided that bumping > > target_read_string first and seeing if anything breaks would be > > better. Haven't heard back of any breakage or slowdown so far. > > I propose we do the same upstream. > > But do you have any targets where reading individual words is slow? You mean slower than reading ~16 words? I doubt there's any where it matters over the latency saved for the current callers of target_read_string. Maybe it would matter if target_read_string and read_string were merged. I don't object to the new packet; I'm merely suggesting avoiding work until proven necessary. The idea is off course sound. > I don't know about any such targets first-hand, but I've heard that > JTAG reading could be exceedingly slow. We use a bunch of different probes, and so do our customers. I don't know offhand which are slow, but they're there for sure. > Another possible alternative is to make this a run-time parameter: > 'maintenance set string-read-size 64' or some such. Default to 64 and > let JTAG people dial it down if it ever becomes a problem for them? I don't envision this being necessary, but I've certainly been wrong before... -- Pedro Alves