From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15798 invoked by alias); 2 Jun 2003 17:09:35 -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 15697 invoked from network); 2 Jun 2003 17:09:34 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 2 Jun 2003 17:09:34 -0000 Received: from dsl093-172-017.pit1.dsl.speakeasy.net ([66.93.172.17] helo=nevyn.them.org ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 19Msp2-0006XH-00; Mon, 02 Jun 2003 12:10:12 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19MsoM-0002F1-00; Mon, 02 Jun 2003 13:09:30 -0400 Date: Mon, 02 Jun 2003 17:09:00 -0000 From: Daniel Jacobowitz To: Richard Henderson Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] better alpha_register_virtual_type Message-ID: <20030602170929.GA8497@nevyn.them.org> Mail-Followup-To: Richard Henderson , gdb-patches@sources.redhat.com References: <20030602050358.GA7443@twiddle.net> <20030602163036.GA7419@nevyn.them.org> <20030602164305.GD9425@twiddle.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030602164305.GD9425@twiddle.net> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-06/txt/msg00074.txt.bz2 On Mon, Jun 02, 2003 at 09:43:05AM -0700, Richard Henderson wrote: > 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. Hmm, that's pretty nice. Sure. > 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? Hum. That seems strange if you look at init_regcache_descr, since gdbarch_register_type and REGISTER_VIRTUAL_TYPE are used similarly. I can't see how legacy_p would affect this. What does ptype $pc say - does it show up as an int64_t or a code pointer? > 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? I don't see what you mean; it's: if (!gdbarch_pseudo_register_read_p (gdbarch) && !gdbarch_pseudo_register_write_p (gdbarch) && !gdbarch_register_type_p (gdbarch)) but gdbarch_register_type_p should be true. "maint print registers" might be handy here. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer