avr-gdb 无法理解我的输入地址答案

【问题标题】：avr-gdb can not understand my input addressavr-gdb 无法理解我的输入地址
【发布时间】：2017-09-08 17:52:35
【问题描述】：

我使用 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吧。

【问题讨论】：

要明确一点，问题是第二个命令将0xc4 转换为0x8000c4，对吗？这很奇怪。

标签： avr simavr

【解决方案1】：

我是 simavr 的作者。抱歉，我不是 stackoverflow 的成员。

您看到这些地址的原因是 gdb/gcc 不能很好地处理具有重叠“地址空间”的架构。 AVR SRAM 从 0x000 开始，AVR Flash 也从 0x000 开始，并且.... eeprom 也被认为是在 0x000——这是“哈佛”架构。

因此，为了使 gcc/gdb 正常工作，所有内容都在“虚拟地址空间”中编译，方法是在这些偏移量上添加一个任意常量——因此故障是 Flash 被认为位于 SRAM 的 0x000（很好！）被认为在 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 上打开并“发布”。

【讨论】：