(gdb) disassemble 0x00000718, 0x00000724 Dump of assembler code from 0x800718 to 0x800724: 0x00800718: nop 0x0080071a: nop 0x0080071c: nop 0x0080071e: nop 0x00800720: nop 0x00800722: nop End of assembler dump. Without arguments the command works as expected: (gdb) disassemble Dump of assembler code for function tasks__cyclic_led_0B: 0x00000718 <+0>: push r29 0x0000071a <+2>: push r28 0x0000071c <+4>: in r28, 0x3d ; 61 0x0000071e <+6>: in r29, 0x3e ; 62 0x00000720 <+8>: sbiw r28, 0x07 ; 7 0x00000722 <+10>: in r0, 0x3f ; 63 0x00000724 <+12>: cli 0x00000726 <+14>: out 0x3e, r29 ; 62 0x00000728 <+16>: out 0x3f, r0 ; 63 0x0000072a <+18>: out 0x3d, r28 ; 61 ... End of assembler dump. (gdb)
Created attachment 13683 [details] screenshot of failed attempt to reproduce bug This is a result of 13519 (https://sourceware.org/bugzilla/show_bug.cgi?id=13519), which has since been resolved. I cannot replicate this issue on GDB 11.0.50 (see attached screenshot). GDB no longer applies the SRAM offset when reading program memory for disassemble operations. I believe this has been fixed since version 10.