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 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上打开并发出'问题'。

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

1 个答案: