From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10052 invoked by alias); 12 Jun 2012 15:32:35 -0000 Received: (qmail 10016 invoked by uid 22791); 12 Jun 2012 15:32:34 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 12 Jun 2012 15:32:21 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q5CFWI6O015714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Jun 2012 11:32:18 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q5CFWGei028090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 12 Jun 2012 11:32:17 -0400 From: Tom Tromey To: "Maciej W. Rozycki" Cc: Subject: Re: [RFC] register_to_value/value_to_register arguments? References: Date: Tue, 12 Jun 2012 15:32:00 -0000 In-Reply-To: (Maciej W. Rozycki's message of "Mon, 11 Jun 2012 10:36:30 +0100") Message-ID: <8739607dhb.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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: 2012-06/txt/msg00355.txt.bz2 >>>>> "Maciej" == Maciej W Rozycki writes: Maciej> However this rises a question: it is relatively expensive to Maciej> retrieve gdbarch from frame, most target implementations of Maciej> these methods need it and it is already readily available to the Maciej> caller (retrieved from the very frame) -- wouldn't it therefore Maciej> make sense to pass it along frame? It seems to me that the frame's arch is cached, so retrieving it is only expensive the first time. Given that, the current approach is clearer and safer, since there's no possibility of arguments being out of sync. Tom