From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5976 invoked by alias); 8 Feb 2002 22:56:48 -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 5830 invoked from network); 8 Feb 2002 22:56:46 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 8 Feb 2002 22:56:46 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 40FE53E7A; Fri, 8 Feb 2002 17:56:41 -0500 (EST) Message-ID: <3C6457A8.4090801@cygnus.com> Date: Fri, 08 Feb 2002 14:56:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.7) Gecko/20020103 X-Accept-Language: en-us MIME-Version: 1.0 To: "Theodore A. Roth" Cc: Daniel Jacobowitz , gdb@sources.redhat.com Subject: Re: gdb support for Atmel AVR References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-02/txt/msg00153.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. 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