From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17059 invoked by alias); 15 Jun 2003 00:02:24 -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 17001 invoked from network); 15 Jun 2003 00:02:23 -0000 Received: from unknown (HELO planck.amplepower.com) (216.39.162.139) by sources.redhat.com with SMTP; 15 Jun 2003 00:02:23 -0000 Received: from [192.168.8.29] (helo=bozoland.mynet) by planck.amplepower.com with esmtp (Exim 3.36 #1 (Debian)) id 19RKnT-0001s4-00; Sat, 14 Jun 2003 16:50:59 -0700 Date: Sun, 15 Jun 2003 00:02:00 -0000 From: "Theodore A. Roth" X-X-Sender: troth@bozoland.mynet To: Daniel Jacobowitz cc: gdb@sources.redhat.com Subject: Re: register_type method In-Reply-To: <20030614223422.GA17448@nevyn.them.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2003-06/txt/msg00290.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. Ted Roth