This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug breakpoints/16703] The program breaks at the next instruction when issuing a memory breakpoint on AVR8.
- From: "palves at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Fri, 14 Mar 2014 10:36:20 +0000
- Subject: [Bug breakpoints/16703] The program breaks at the next instruction when issuing a memory breakpoint on AVR8.
- Auto-submitted: auto-generated
- References: <bug-16703-4717 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=16703
--- Comment #4 from Pedro Alves <palves at redhat dot com> ---
/* Not all avr devices support the BREAK insn. Those that don't should treat
it as a NOP. Thus, it should be ok. Since the avr is currently a remote
only target, this shouldn't be a problem (I hope). TRoth/2003-05-14 */
static const unsigned char *
avr_breakpoint_from_pc (struct gdbarch *gdbarch,
CORE_ADDR *pcptr, int *lenptr)
{
static const unsigned char avr_break_insn [] = { 0x98, 0x95 };
*lenptr = sizeof (avr_break_insn);
return avr_break_insn;
}
So we're using the BREAK insn.
At http://www.atmel.com/images/doc0856.pdf , for BREAK, we see:
"Program Counter: PC â PC + 1"
So looks like that's what the hardware is supposed to do.
But then I'm very much mystified how the port has managed to work all these
years, and worry about breaking remote targets. Could this be a case of
everyone has always been using an out of tree gdb that carries a
decr_pc_after_break patch?
--
You are receiving this mail because:
You are on the CC list for the bug.