From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26472 invoked by alias); 8 Feb 2002 22:29:33 -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 26399 invoked from network); 8 Feb 2002 22:29:30 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 8 Feb 2002 22:29:30 -0000 Received: from drow by nevyn.them.org with local (Exim 3.34 #1 (Debian)) id 16ZJWL-0000hm-00; Fri, 08 Feb 2002 17:29:29 -0500 Date: Fri, 08 Feb 2002 14:29:00 -0000 From: Daniel Jacobowitz To: "Theodore A. Roth" Cc: gdb@sources.redhat.com Subject: Re: gdb support for Atmel AVR Message-ID: <20020208172929.A2520@nevyn.them.org> Mail-Followup-To: "Theodore A. Roth" , gdb@sources.redhat.com References: <20020208142022.A27446@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i X-SW-Source: 2002-02/txt/msg00151.txt.bz2 On Fri, Feb 08, 2002 at 03:26:28PM -0700, Theodore A. Roth wrote: > On Fri, 8 Feb 2002, Daniel Jacobowitz wrote: > > :)I really do not think that TARGET_REMOTE_ADDR_BIT should be > :)necessary... in what way was TARGET_ADDR_BIT/TARGET_POINTER_BIT > :)inadequate? Do you have different sized code and data pointers? > > Code and data pointers are both 16-bit. The problem is we use some of the > bits 31-16 to flag whether gdb is asking for code (flash) or data (sram) > space. Using "remote_address_size = TARGET_ADDR_BIT;" in remote.c causes > gdb to mask off the upper 16 bits thus removing the flag. Without the > flag, the target will always think it is accessing code space. > > Basically, I've tricked gdb into storing ptrs and addresses into 32 bit > numbers while it still thinks that they are both 16 bits. I need all 32 > bits sent to the target, but when gdb issues an 'm' packet for say a > struct, it must request the right number of bytes from the remote target. > > I got burned by this when I set remoteaddresssize to 32. Gdb would ask for > 4 bytes at some address and then dereference the return value thinking the > value was a ptr. Needless to say, the 32 ptr pointed to the wrong data. > > :) > :)Oh, reading further down the patch I see that AVR is a Harvard > :)architecture. There is support for this in GDB, with > :)CODE_SPACE/DATA_SPACE that were recently introduced (for the d10v, I > :)think). You may have some problems if they are of different size, I > :)suppose. > > I modeled some of my work on the d10v-tdep.c file in gdb-5.1. Looking at > the d10v from cvs, I see the use of TYPE_CODE_SPACE in the > d10v_pointer_to_address function. This may help with some other things in > my code, but I don't think it stops the problem described above. I think it ought to, but again I'll defer to someone with a better understanding of how d10v handles this. It appears to be rather different. > :)Also, I think (.avrgdbinit aside...) that you should not have a > :)tm-avr.h at all. You can set multi-arch from configure.tgt. > > Easy enough to change. Done. > > Is there any other way to set GDBINIT_FILENAME? Shouldn't that be part of > multi-arch? If it could be set via multi-arch, I wouldn't need tm-avr.h. > Since avr-gdb is always going to be a cross tool, I think I should be > using .avrgdbinit to allow native gdb to use .gdbinit, right? No other port bothers. It's never been a real problem for me; .gdbinit goes in object directories generally. > I'd also like a critic on my changes to > eval.c/printcmd.c/value.h/values.c which where necessary to get the > disassemble command to function properly. You'd really need a comment from one of the d10v folks on this. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer