From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19572 invoked by alias); 1 Jul 2013 16:07:02 -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 19561 invoked by uid 89); 1 Jul 2013 16:07:01 -0000 X-Spam-SWARE-Status: No, score=-7.4 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 01 Jul 2013 16:07:01 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r61G70Mt021055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 1 Jul 2013 12:07:00 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r61G6wD7022719; Mon, 1 Jul 2013 12:06:59 -0400 Message-ID: <51D1A922.9090707@redhat.com> Date: Mon, 01 Jul 2013 16:07:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Tom Tromey CC: gdb-patches@sourceware.org Subject: Re: [PATCH 11/16] move some statics from remote_read_qxfer into struct remote_state References: <1372441229-305-1-git-send-email-tromey@redhat.com> <1372441229-305-12-git-send-email-tromey@redhat.com> In-Reply-To: <1372441229-305-12-git-send-email-tromey@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-07/txt/msg00040.txt.bz2 On 06/28/2013 06:40 PM, Tom Tromey wrote: > This moves a few static variables out of remote_read_qxfer and into > remote_state. It is unclear to me if this data can ever be required > to be kept around across a potential target switch, but it is > definitely safe to move it into the remote state object. Hmm, are we still unclear about it? It seems to me that if we dropped the data, we'd always be able to re-fetch it, though obviously we'd lose on the optimization. It definitely seems to me that putting it in the remote state object is the correct choice. Maybe you're seeing something I'm not though. -- Pedro Alves