From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16564 invoked by alias); 2 Jun 2003 16:43:51 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 16513 invoked from network); 2 Jun 2003 16:43:50 -0000 Received: from unknown (HELO are.twiddle.net) (64.81.246.98) by sources.redhat.com with SMTP; 2 Jun 2003 16:43:50 -0000 Received: from are.twiddle.net (localhost.localdomain [127.0.0.1]) by are.twiddle.net (8.12.8/8.12.8) with ESMTP id h52GhYLH009658 for ; Mon, 2 Jun 2003 09:43:34 -0700 Received: (from rth@localhost) by are.twiddle.net (8.12.8/8.12.8/Submit) id h52Gh50Y009655 for gdb-patches@sources.redhat.com; Mon, 2 Jun 2003 09:43:05 -0700 X-Authentication-Warning: are.twiddle.net: rth set sender to rth@twiddle.net using -f Date: Mon, 02 Jun 2003 16:43:00 -0000 From: Richard Henderson To: gdb-patches@sources.redhat.com Subject: Re: [RFA] better alpha_register_virtual_type Message-ID: <20030602164305.GD9425@twiddle.net> References: <20030602050358.GA7443@twiddle.net> <20030602163036.GA7419@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030602163036.GA7419@nevyn.them.org> User-Agent: Mutt/1.4i X-SW-Source: 2003-06/txt/msg00072.txt.bz2 On Mon, Jun 02, 2003 at 12:30:36PM -0400, Daniel Jacobowitz wrote: > Yes. I was a little surprised by the void_data_ptr/void_func_ptr bit, > but I see that d10v does the same thing, so it must be right :) > > Hmm, I'm not sure. Any particular reason for this patch? Well, the void_func_ptr bit is nice because "info r" yields pc 0x12000053c 0x12000053c The void_data_ptr bits I think just document which registers are ABI mandated to contain pointer values all of the time. Actually, I have a related question here. Something that I didn't notice earlier is that d10v is using register_type, not register_virtual_type. Looking at the guts of regcache.c, it would appear that the later is deprecated, since not having a register_type hook (among other things) results in legacy_p being set. I thought it obvious to rename my existing hook, but that changes the behaviour of "info r" -- I no longer get the pc decoded, and indeed "ptype $pc" once again yields int64_t. Is this a bug elsewhere in gdb, or what? Oh, and wrt regcache's legacy_p, it seems to want you to implement the pseudo_register_{read,write} hooks, even if the target doesn't have any. But nevertheless d10v doesn't implement the hooks. Perhaps the predicates should be modified to notice that there are no pseudos defined? r~