From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7421 invoked by alias); 8 Feb 2002 22:19:00 -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 7243 invoked from network); 8 Feb 2002 22:18:57 -0000 Received: from unknown (HELO pasiphae01.frii.com) (216.17.128.33) by sources.redhat.com with SMTP; 8 Feb 2002 22:18:57 -0000 Received: from deimos.frii.net (deimos.frii.com [216.17.128.2]) by pasiphae01.frii.com (8.12.2/8.12.2) with ESMTP id g18MIubZ037635; Fri, 8 Feb 2002 15:18:56 -0700 (MST) Received: from ari-co2d-249.rasserver.net (ari-co2d-249.rasserver.net [207.92.202.249]) by deimos.frii.net (8.12.2/8.12.2) with ESMTP id g18MIqaJ025008; Fri, 8 Feb 2002 15:18:53 -0700 (MST) Date: Fri, 08 Feb 2002 14:19:00 -0000 From: "Theodore A. Roth" X-X-Sender: troth@bozoland.mynet To: Daniel Jacobowitz cc: gdb@sources.redhat.com Subject: Re: gdb support for Atmel AVR In-Reply-To: <20020208142022.A27446@nevyn.them.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-02/txt/msg00150.txt.bz2 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. :)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? 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. Ted Roth