From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31498 invoked by alias); 13 Jul 2011 20:52:29 -0000 Received: (qmail 31486 invoked by uid 22791); 13 Jul 2011 20:52:28 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_EG X-Spam-Check-By: sourceware.org Received: from mail-ey0-f169.google.com (HELO mail-ey0-f169.google.com) (209.85.215.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 13 Jul 2011 20:52:09 +0000 Received: by eyd9 with SMTP id 9so2528903eyd.0 for ; Wed, 13 Jul 2011 13:52:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.26.138 with SMTP id e10mr500928ebc.120.1310590327904; Wed, 13 Jul 2011 13:52:07 -0700 (PDT) Received: by 10.213.29.195 with HTTP; Wed, 13 Jul 2011 13:52:07 -0700 (PDT) In-Reply-To: References: Date: Thu, 14 Jul 2011 04:24:00 -0000 Message-ID: Subject: Re: RFC: partially available registers From: Daniel Jacobowitz To: Tom Tromey Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg00361.txt.bz2 I'm too stale to properly review this patch, but I have some comments. On Wed, Jul 13, 2011 at 1:44 PM, Tom Tromey wrote: > This patch fixes the problem by letting an arch register a new > pseudo_register_read_value method, which is responsible for constructing > a struct value for the register. =A0This gives us a chance to mark > just some bits unavailable. I think this is the right approach. We should move more towards values, not away; in particular, I do not prefer this alternative: > * Rather than a way to return values, have a different API, say one > =A0where gdb requests the first N bytes of a register. As for the patch itself: * Some documentation on the gdbarch method would be nice, in particular, the return value. Does 0 mean "not a pseudo"? * Stale comment in sentinel_frame_prev_register. * I am not happy about having to implement both gdbarch_pseudo_register_read and gdbarch_pseudo_register_read_value, depending on which regcache read function was called. So for a final version, is it practical to push this down and only call the value version if it is registered? That means implementing the existing regcache read in terms of the new one, instead of the other way around. -- Thanks, Daniel