gdb support for Atmel AVR

[Andrew Cagney]

> 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