2

我使用 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看不懂我输入的地址，加个offset。

4

1 回答 1

2

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

您看到这些地址的原因是 gdb/gcc 不能很好地处理具有重叠“地址空间”的架构。AVR SRAM 从 0x000 开始，AVR Flash 也从 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 上打开并“发布”。

于 2017-09-21T07:26:09.587 回答