From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94577 invoked by alias); 20 Jun 2016 19:25:52 -0000 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 Received: (qmail 94567 invoked by uid 89); 20 Jun 2016 19:25:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=transfer, our X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 20 Jun 2016 19:25:50 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4EBF97F6A2; Mon, 20 Jun 2016 19:25:49 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5KJPlVl025139; Mon, 20 Jun 2016 15:25:48 -0400 Subject: Re: [PATCH] Optimize memory_xfer_partial for remote To: Don Breazeal , gdb-patches@sourceware.org References: <1464980562-24184-1-git-send-email-donb@codesourcery.com> From: Pedro Alves Message-ID: Date: Mon, 20 Jun 2016 19:25:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <1464980562-24184-1-git-send-email-donb@codesourcery.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-06/txt/msg00339.txt.bz2 On 06/03/2016 08:02 PM, Don Breazeal wrote: > I considered making target_set_memory_xfer_limit a function in the target > vector, but concluded that was overkill. In this patch it is an external > function in target.c. Sorry, but that doesn't make sense. If in the same session you switch to another target (e.g., core or native debugging), you'll continue using the limit set up by the previous remote connection. There's also an effort to teach gdb about connecting to multiple remote targets at the same time. A global like this would need to be adjusted to per-connection anyway. So seems to be we should have a real target_get_memory_xfer_limit() (or some such) target method. > > + /* Set the cap on memory transfer requests to our packet size. */ > + target_set_memory_xfer_limit (get_remote_packet_size ()); Shouldn't this be based on get_memory_write_packet_size() instead? Thanks, Pedro Alves