From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17842 invoked by alias); 15 Jun 2003 00:16:55 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 17807 invoked from network); 15 Jun 2003 00:16:54 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.166.107) by sources.redhat.com with SMTP; 15 Jun 2003 00:16:54 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 828C62B5F; Sat, 14 Jun 2003 20:16:35 -0400 (EDT) Message-ID: <3EEBBAE3.70801@redhat.com> Date: Sun, 15 Jun 2003 00:16: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: "Theodore A. Roth" Cc: Daniel Jacobowitz , gdb@sources.redhat.com Subject: Re: register_type method References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-06/txt/msg00292.txt.bz2 > On Sat, 14 Jun 2003, Daniel Jacobowitz wrote: > > :)On Sat, Jun 14, 2003 at 03:27:00PM -0700, Theodore A. Roth wrote: > :)> Hi, > :)> > :)> What builtin type should the *_register_type method return for the PC? > :)> > :)> I would think that it it should be builtin_type_void_func_ptr like the d10v > :)> does, but when I use that for the avr, I only get 2 bytes for the PC > :)> register size and I need 4 bytes. Using builtin_type_uint32 works but just > :)> doesn't feel right. > :)> > :)> I also tried using builtin_type_CORE_ADDR and that seemed to work as well as > :)> builtin_type_uint32. > :)> > :)> Here's my avr_register_type method I'm currently playing with: > :) > :)I've only been mostly-following previous discussions of the AVR, but - > :)why do you need a different number of bytes for a void (*)() than you > :)do for the PC? It seems to me that the PC should always be converted > :)(is this still POINTER_TO_ADDRESS?) in the same way a void (*)() would > :)be. > > That's a good question. I'm not sure I have an answer which is probably the > root of my confusion. I think you are correct that convertion should be the > same. I just did some comparison of the d10v and avr *_make_?addr() and > *_convert_?addr_to_raw() functions and it looks like the avr might not be > using those to the extent that it should not to mention a few > inconsistencies I just noticed. :-( > > Our remote targets (a simulator and a jtag ice glue program) try to do the > word address to byte address translation before replying to gdb queries. I'm > beginning to wonder if that was a mistake since we then have some > translations done on the gdb side and some on the remote target side. Thus > making things much more complicated than they need to be. > > Looks like I need to give this more thought and rework it a bit. > > In the mean time, is there any objections to me finishing up the merging of > my frame-ify and removal of deprecated interface changes? I have those > working now and they work better than what is currently in cvs. > > Once I get that merge done, I can rework the ptr and address convertions to > be a bit more sane. If I understand right, the 4 byte PC is due to an historic decision related to the remote protocol (dates back to before pointer to address). Try making the "pc" a 2 byte pseudo register that that the architecture pseudo read/write methods map onto a corresponding raw register. Andrew