Re: gdb support for Atmel AVR

["Theodore A. Roth" <troth at verinet dot com>]

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