From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26126 invoked by alias); 8 Feb 2002 23:10:56 -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 26073 invoked from network); 8 Feb 2002 23:10:54 -0000 Received: from unknown (HELO pasiphae02.frii.com) (216.17.128.34) by sources.redhat.com with SMTP; 8 Feb 2002 23:10:54 -0000 Received: from deimos.frii.net (deimos.frii.com [216.17.128.2]) by pasiphae02.frii.com (8.12.2/8.12.2) with ESMTP id g18NAntF018227; Fri, 8 Feb 2002 16:10:49 -0700 (MST) Received: from 199.182.88.203.ras03.den.iras.frii.net (199.182.88.203.ras03.den.iras.frii.net [199.182.88.203]) by deimos.frii.net (8.12.2/8.12.2) with ESMTP id g18NAlck069386; Fri, 8 Feb 2002 16:10:48 -0700 (MST) Date: Fri, 08 Feb 2002 15:10:00 -0000 From: "Theodore A. Roth" X-X-Sender: troth@bozoland.mynet To: Andrew Cagney cc: Daniel Jacobowitz , Subject: Re: gdb support for Atmel AVR In-Reply-To: <3C6457A8.4090801@cygnus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-02/txt/msg00154.txt.bz2 Looks like I need to do some more work then. Thanks for the explanation. Ted Roth On Fri, 8 Feb 2002, Andrew Cagney wrote: :)> 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. :) :) :)TARGET_ADDR_BIT is the number of significant bits in a CORE_ADDR. For :)your target that is 32. The remote protocol will use those 32 bits when :) requesting raw memory. :) :)Separatly, you've got 16 bit pointers you need TARGET_PTR_BIT=16. GDB :)uses the functions pointer_to_address() and address_to_pointer() when :)converting a C code/data pointer to/from a CORE_ADDR. :) :)BTW, the d10v is even more fun. Data pointers are 16 bits and point to :)an 8 bit byte. Code pointers are also 16 bits but point to a 16 bit :)word. Consequently some shifting also occures when converting to/from :)CORE_ADDRS. This all works with out cpu specific changes to core GDB. :) :) :)> 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. :) :) :)The d10v was doing something like that but has since been fixed. :) :) :)> 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. :) :) :)I'd try the above. :) :)enjoy, :)Andrew :) :) :) :)