Created attachment 7469 [details] Simple program ran on the ATxmega256a3b chip When setting breakpoints on AVR, using gdb against the simulator models, using the ATxmega256a3u, the program counter needs to be decremented after a breakpoint is hit. This only happens with memory breakpoints. ------------------------------------------------------------------------------ GNU gdb (AVR 8-bit toolchain (built 20140310)) 7.7.50.20140313-cvs Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=avr". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.atmel.com>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". (gdb) set re[K[Kdebug remote 1 (gdb) target remote :51000 Remote debugging using :51000 0x0000020e in ?? () (gdb) file atxmega-test.elf A program is being debugged already. Are you sure you want to change the file? (y or n) Reading symbols from atxmega-test.elf...done. (gdb) load Loading section .text, size 0x22e lma 0x0 Start address 0x0, load size 558 Transfer rate: 544 KB/sec, 186 bytes/write. (gdb) monitor reset (gdb) break main Breakpoint 1 at 0x204: file main.c, line 7. (gdb) continue Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x00000206 in main () at main.c:7 7 PORTR.DIRSET = 3; (gdb) break *(@code void *) 0x106 Breakpoint 2 at 0x20c: file main.c, line 8. (gdb) continue Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x0000020e in main () at main.c:8 8 PORTR.OUTSET = 1; (gdb) p/x $pc $1 = 0x20e (gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y 0x00000204 in main at main.c:7 2 breakpoint keep y 0x0000020c in main at main.c:8 (gdb) q A debugging session is active. Inferior 1 [Remote target] will be killed. Quit anyway? (y or n)
What does the hardware do? Is this specific to "ATxmega256a3u", or all parts, or a bug in the sim?
Also, what happens with regular symbol breakpoints? E.g., "b main".
Nevermind the last question, it's visible in the original description: (gdb) break main Breakpoint 1 at 0x204: file main.c, line 7. ^^^^ (gdb) continue Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x00000206 in main () at main.c:7 ^^^ 7 PORTR.DIRSET = 3; Good, I was scratching my head over how it could ever be different. :-)
/* 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?
Hello Pedro, The reason why this has not been addressed is because memory breakpoint are only supported by the simulation models. On real hardware, memory breakpoints are not possible due to the flash memory being read-only. So I believe up until now, only hardware breakpoints have been used. For instance, I ran the same test using AVaRice (see the following GDB session), and it resorts to hardware breakpoints. AVaRice reports the following memory-map: Sending packet: $qXfer:memory-map:read::0,18a#b4...Ack Packet received: l<memory-map>\n <memory type="ram" start="0x800000" length="0x20000" />\n <memory type="flash" start="0" length="0x48400">\n <property name="blocksize">0x80</property>\n </memory>\n</memory-map>\n Resulting in this: Note: automatically using hardware breakpoints for read-only addresses. ---------------------------------------------------------------------------- GNU gdb (AVR 8-bit toolchain (built 20140310)) 7.7.50.20140314-cvs Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=avr". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.atmel.com>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". (gdb) file atxmega-test.elf Reading symbols from atxmega-test.elf...done. (gdb) set debug remote 1 (gdb) target remote :4242 Remote debugging using :4242 Sending packet: $qSupported:multiprocess+;qRelocInsn+#2a...Ack Packet received: qXfer:memory-map:read+ Packet qSupported (supported-packets) is supported Sending packet: $Hg0#df...Ack Packet received: Sending packet: $qTStatus#49...Ack Packet received: Packet qTStatus (trace-status) is NOT supported Sending packet: $?#3f...Ack Packet received: S05 Sending packet: $qfThreadInfo#bb...Ack Packet received: Sending packet: $qL1160000000000000000#55...Ack Packet received: Sending packet: $Hc-1#09...Ack Packet received: Sending packet: $qC#b4...Ack Packet received: Sending packet: $qAttached#8f...Ack Packet received: Packet qAttached (query-attached) is NOT supported Sending packet: $qOffsets#4b...Ack Packet received: Sending packet: $g#67...Ack Packet received: 000000000000000000000000000000000000000000000000000000000000000000ff5f00000000 0x00000000 in __vectors () Sending packet: $qSymbol::#5b...Ack Packet received: Packet qSymbol (symbol-lookup) is NOT supported (gdb) break main Sending packet: $qXfer:memory-map:read::0,18a#b4...Ack Packet received: l<memory-map>\n <memory type="ram" start="0x800000" length="0x20000" />\n <memory type="flash" start="0" length="0x48400">\n <property name="blocksize">0x80</property>\n </memory>\n</memory-map>\n Sending packet: $m204,2#61...Ack Packet received: 83e0 Breakpoint 1 at 0x204: file main.c, line 7. (gdb) c Continuing. Note: automatically using hardware breakpoints for read-only addresses. Sending packet: $Z1,204,2#ab...Ack Packet received: OK Packet Z1 (hardware-breakpoint) is supported Sending packet: $vCont?#49...Ack Packet received: Packet vCont (verbose-resume) is NOT supported Sending packet: $Hc0#db...Ack Packet received: Sending packet: $c#63...Ack Packet received: T0520:00;21:fc5f;22:04020000; Sending packet: $z1,204,2#cb...Ack Packet received: OK Breakpoint 1, main () at main.c:7 7 PORTR.DIRSET = 3; (gdb) q A debugging session is active. Inferior 1 [Remote target] will be killed. Quit anyway? (y or n) y
Memory map support was added in 2006-09-21, and the avr port goes all the back back to at least 2002-04-25. Given the flash issue, I think that it's quite likely that older remote targets / servers just handled Z0 packets as hardware breakpoints behind the scenes, and therefore reported the PC as the breakpoint's address. So setting decr_pc_after_break would break those old stubs/servers/etc. I don't if we should care. Assuming all probes nowadays send a memory map, probably not. Tristan, any comments?