This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb support for Atmel AVR
- From: "Theodore A. Roth" <troth at verinet dot com>
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Cc: Daniel Jacobowitz <drow at mvista dot com>, <gdb at sources dot redhat dot com>
- Date: Fri, 8 Feb 2002 16:18:27 -0700 (MST)
- Subject: Re: gdb support for Atmel AVR
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
:)
:)
:)
:)