Re: gdb support for Atmel AVR

[Daniel Jacobowitz <drow@mvista.com>]

On Fri, Feb 08, 2002 at 03:26:28PM -0700, Theodore A. Roth wrote:
> 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.

I think it ought to, but again I'll defer to someone with a better
understanding of how d10v handles this.  It appears to be rather
different.

> :)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?

No other port bothers.  It's never been a real problem for me; .gdbinit
goes in object directories generally.

> 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.

You'd really need a comment from one of the d10v folks on this.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer