This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug breakpoints/16703] The program breaks at the next instruction when issuing a memory breakpoint on AVR8.


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]