This is the mail archive of the
mailing list for the GDB project.
RE: breakpoint at address on Atmel AVR - parsing
- From: "Weddington, Eric" <Eric dot Weddington at atmel dot com>
- To: Joel Brobecker <brobecker at adacore dot com>, Petr Hluz?n <petr dot hluzin at gmail dot com>
- Cc: gdb <gdb at sourceware dot org>
- Date: Fri, 24 Aug 2012 23:01:16 +0000
- Subject: RE: breakpoint at address on Atmel AVR - parsing
- References: <20120816231002.GC6058@adacore.com>
> -----Original Message-----
> From: Joel Brobecker
> Sent: Thursday, August 16, 2012 5:10 PM
> To: Petr Hluz?n
> Cc: gdb
> Subject: Re: breakpoint at address on Atmel AVR - parsing
> > It seems GDB-7.4.91 badly parses program-space addresses given to
> > `break' and `disassemble' at Atmel AVR architecture: an "0x4d2"
> > becomes 0x8004d2.
> As I understand it, this is a bit of an unfortunate "expected behavior"
> at the moment.
> One possible way to fix it, I think, it to enhance the linespec module
> (used by the "break" command) and the "disassemble" command to automatically
> treat integer values as code addresses. For instance, in the case
> of the "disassemble" command, perhaps it would be sufficient to
> simply cast the value obtained after parsing to a code pointer,
> before extracting the value as an address:
> pc = value_as_address (parse_to_comma_and_eval (&arg));
> After all, the command knows that the address should be code addresses,
> not data addresses.
Adding 0x800000 to all code-space addresses has been part of AVR GCC for many years, mainly to distinguish when an address is in the code space. The AVR is Harvard architecture with multiple address spaces, but GCC expects Von Neumann architecture with a single address space. The solution was to create a very high offset to indicate that the address was in code.