From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12414 invoked by alias); 11 Jun 2012 09:37:06 -0000 Received: (qmail 12198 invoked by uid 22791); 11 Jun 2012 09:37:04 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 11 Jun 2012 09:36:43 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1Se13C-0006Yr-DX from Maciej_Rozycki@mentor.com for gdb-patches@sourceware.org; Mon, 11 Jun 2012 02:36:42 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Jun 2012 02:36:41 -0700 Received: from [172.30.0.208] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Mon, 11 Jun 2012 10:36:39 +0100 Date: Mon, 11 Jun 2012 09:37:00 -0000 From: "Maciej W. Rozycki" To: Subject: [RFC] register_to_value/value_to_register arguments? Message-ID: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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/msg00275.txt.bz2 Hello, While doing some changes recently I have come across this inconsistency in our internal document when it comes to register_to_value and value_to_register gdbarch method arguments (patch below). However this rises a question: it is relatively expensive to retrieve gdbarch from frame, most target implementations of these methods need it and it is already readily available to the caller (retrieved from the very frame) -- wouldn't it therefore make sense to pass it along frame? Why wasn't it done like this when the API was changed according to this documentation patch? Maciej 2012-06-11 Maciej W. Rozycki gdb/doc/ * gdbint.texinfo (Using Different Register and Memory Data Representations): Update gdbarch_register_to_value and gdbarch_value_to_register arguments. gdb-doc-gdbint-regconv.diff Index: gdb-fsf-trunk-quilt/gdb/doc/gdbint.texinfo =================================================================== --- gdb-fsf-trunk-quilt.orig/gdb/doc/gdbint.texinfo 2012-06-01 18:42:43.205559049 +0100 +++ gdb-fsf-trunk-quilt/gdb/doc/gdbint.texinfo 2012-06-11 10:17:24.713600380 +0100 @@ -3726,7 +3726,7 @@ If defined, this function should return type, when no conversion is necessary. @end deftypefn -@deftypefn {Architecture Function} void gdbarch_register_to_value (struct gdbarch *@var{gdbarch}, int @var{reg}, struct type *@var{type}, char *@var{from}, char *@var{to}) +@deftypefn {Architecture Function} void gdbarch_register_to_value (struct gdbarch *@var{gdbarch}, struct frame_info *@var{frame}, int @var{reg}, struct type *@var{type}, char *@var{from}, char *@var{to}) Convert the value of register number @var{reg} to a data object of type @var{type}. The buffer at @var{from} holds the register's value @@ -3745,7 +3745,7 @@ non-zero value. @end deftypefn -@deftypefn {Architecture Function} void gdbarch_value_to_register (struct gdbarch *@var{gdbarch}, struct type *@var{type}, int @var{reg}, char *@var{from}, char *@var{to}) +@deftypefn {Architecture Function} void gdbarch_value_to_register (struct gdbarch *@var{gdbarch}, struct frame_info *@var{frame}, struct type *@var{type}, int @var{reg}, char *@var{from}, char *@var{to}) Convert a data value of type @var{type} to register number @var{reg}' raw format.