From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22160 invoked by alias); 2 Jun 2003 19:06:29 -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 22139 invoked from network); 2 Jun 2003 19:06:29 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.131) by sources.redhat.com with SMTP; 2 Jun 2003 19:06:29 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id F2E1A2B2F; Mon, 2 Jun 2003 15:06:19 -0400 (EDT) Message-ID: <3EDBA02B.6090201@redhat.com> Date: Mon, 02 Jun 2003 19:06:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard Henderson Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] better alpha_register_virtual_type References: <20030602050358.GA7443@twiddle.net> <20030602163036.GA7419@nevyn.them.org> <20030602164305.GD9425@twiddle.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-06/txt/msg00082.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 :) For the d10v it is 100% right. The d10v's PC needs to be a code pointer so that it it is automatically converted into a CORE_ADDR when used in equations vis: (gdb) ptype $pc type = void (*)() (gdb) x/i $pc 0x10140b8 : ld r0, @r11 || nop (gdb) print/x $pc $1 = 0x10140b8 (gdb) print/x (int)$pc $2 = 0x502e >> 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. Something weird is happening. The only thing notable about the d10v is that it doesn't set PC_REGNUM (per above, the d10v works). Perhaphs the alpha definition is confusing std-regs.c / builtin-regs.c (but that doesn't make much sense). > Is this a bug elsewhere in gdb, or what? Perhaps. Andrew