avr-gdb无法识别我的输入地址

Question

我使用simavr和avr-gdb调试一个.hex文件，问题是：

(gdb) i r pc
pc             0xcd0    0xcd0
(gdb) x/10i 0xc4
   0x8000c4:    nop
   0x8000c6:    nop
   0x8000c8:    nop
   0x8000ca:    nop
   0x8000cc:    nop
   0x8000ce:    nop
   0x8000d0:    nop
   0x8000d2:    nop
   0x8000d4:    nop
   0x8000d6:    nop
(gdb) x/10i $pc-0xc0c
   0xc4:        eor     r1, r1
   0xc6:        out     0x3f, r1        ; 63
   0xc8:        ldi     r28, 0xFF       ; 255
   0xca:        ldi     r29, 0x08       ; 8
   0xcc:        out     0x3e, r29       ; 62
   0xce:        out     0x3d, r28       ; 61
   0xd0:        ldi     r17, 0x05       ; 5
   0xd2:        ldi     r26, 0x00       ; 0
   0xd4:        ldi     r27, 0x01       ; 1
   0xd6:        ldi     r30, 0xEA       ; 234
(gdb)

似乎avr-gdb无法理解我的输入地址，并添加了一个偏移量。

Answer 1

我是simavr的作者。对不起，我不是stackoverflow的成员。

您看到这些地址的原因是gdb/gcc不能很好地处理具有重叠“地址空间”的体系结构。AVR SRAM从0x000开始，AVR闪存也从0x000开始，...eeprom也被认为是0x000 --这就是‘哈佛’架构。

因此，为了让gcc/gdb正常工作，所有东西都是在“虚拟地址空间”中编译的，方法是在这些偏移量上添加一个任意常量--所以详细说明就是Flash被认为是0x000 (好吧！)SRAM被认为是0x800000，eeprom是0x810000。

这让gcc/gdb感到高兴--然而，代价是你会在调试时看到这些奇怪的东西被处理，因为gdb坚信一切都在这些偏移量上。

处理这件事最好的办法就是...忽略它！我们无能为力--它不是我想出来的，早在2009年simavr开始之前很久，它就被引入了avr-gcc。

你可以在那里看到simavr地址的“地址解码器”，也许它会让事情变得更清楚一些。https://github.com/buserror/simavr/blob/4c9efe1fc44b427a4ce1ca8e56e0843c39d0014d/simavr/sim/sim_gdb.c#L357

希望对您有所帮助--如果您有更多的问题，请随时访问freenode #simavr，甚至在github上打开并‘问题’。