This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug gdb/13519] [avr][Regression 7.1/7.2/7.3/7.4] disassemble command attempts to disassemble SRAM rather than program memory
- From: "cristiano.dealti at eurotech dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Sun, 24 May 2015 17:40:58 +0000
- Subject: [Bug gdb/13519] [avr][Regression 7.1/7.2/7.3/7.4] disassemble command attempts to disassemble SRAM rather than program memory
- Auto-submitted: auto-generated
- References: <bug-13519-4717 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=13519
cristiano.dealti at eurotech dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #6243|0 |1
is obsolete| |
Attachment #7692|0 |1
is obsolete| |
--- Comment #13 from cristiano.dealti at eurotech dot com ---
Created attachment 8330
--> https://sourceware.org/bugzilla/attachment.cgi?id=8330&action=edit
Final patch to broken AVR arch with the latest gdbs
This patch obsoletes all previous patches attached to this bug.
The patch is trivial and only affects avr-tdep.c.
As noted by others, avr_integer_to_address() always returns addresses in SRAM.
However, the second parameter of this function, struct type *type, allows to
understand if a code or data address is desired.
Indeed, patch is so simple that the patched function is simply:
static CORE_ADDR
avr_integer_to_address (struct gdbarch *gdbarch,
struct type *type, const gdb_byte *buf)
{
ULONGEST addr = unpack_long (type, buf);
if (TYPE_DATA_SPACE (type))
return avr_make_saddr (addr);
else
return avr_make_iaddr (addr);
}
Everything works: disassemble, breakpoints at numeric address, breakpoints at
source line and watchpoints.
--
You are receiving this mail because:
You are on the CC list for the bug.