Gdb 在调试 ARM7 微控制器的汇编程序时跳过源代码行
我在调试用 ARM7 微控制器 (AT91SAM7S64) 的汇编语言编写的简单程序时遇到问题。我使用 gcc、gdb 和 OpenOCD。 我的程序已正确加载到目标并且工作正常(LED 闪烁)。但是当我调用“next”命令时,gdb 会跳过某些源代码行。
这是源代码的片段:
Reset_Handler:
LDR R0, =0x0100
LDR R1, =PIOA_PER
STR R0, [R1]
LDR R1, =PIOA_OER
STR R0, [R1]
uuu:
bl wait;
LDR R1, =PIOA_SODR
STR R0, [R1]
uuu1:
bl wait;
LDR R2, =PIOA_CODR
STR R0, [R2]
b uuu;
@ one second delay
wait:
.............
.............
.end
为了获得 gdb 输出(见下文),我使用了“target sim”而不是真实目标,但结果完全相同。
(gdb) target sim
Connected to the simulator.
(gdb) load
Loading section .text, size 0xc8 vma 0x100000
Start address 0x100000
Transfer rate: 1600 bits in <1 sec.
(gdb) b Reset_Handler
Breakpoint 1 at 0x100064: file main.s, line 59.
(gdb) run
Starting program: C:\Arm\Projects\Asm/./main.elf
Breakpoint 1, Reset_Handler () at main.s:60
60 LDR R1, =PIOA_PER
(gdb) n
61 STR R0, [R1]
(gdb) n
63 LDR R1, =PIOA_OER
(gdb) n
64 STR R0, [R1]
(gdb) n
uuu () at main.s:66
66 bl wait;
(gdb) n
67 LDR R1, =PIOA_SODR
(gdb) n
68 STR R0, [R1]
(gdb) n <<<<<--------- Here the problem begins
67 LDR R1, =PIOA_SODR
(gdb) n
68 STR R0, [R1]
(gdb) n
67 LDR R1, =PIOA_SODR
(gdb) n
68 STR R0, [R1]
(gdb) stepi <<<<<------ Doing a 'stepi' command allows to pass below 'uuu1' label
uuu1 () at main.s:70
70 bl wait;
(gdb) n
71 LDR R2, =PIOA_CODR
(gdb) n
72 STR R0, [R2]
(gdb) n
73 b uuu;
(gdb) n <<<<<--------- Here the problem begins again
71 LDR R2, =PIOA_CODR
(gdb) n
72 STR R0, [R2]
(gdb) n
73 b uuu;
(gdb) n
71 LDR R2, =PIOA_CODR
(gdb) where
#0 uuu1 () at main.s:71
#1 0x00100084 in uuu1 () at main.s:70
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
看起来 gdb 假定 'uuu1' 作为一个单独的函数并由于某种原因跳过它。如果我删除“uuu1”标签,问题就会消失。这个标签没有在任何地方使用,但 gdb 的行为看起来很奇怪。我很长时间以来一直在尝试寻找任何解决方案,但取得了显着的成果。使用 gcc 选项“-fomit-frame-pointer”没有帮助。 我能做什么呢?
gdb 和 gcc 的版本:
arm-none-eabi-gdb --version
GNU gdb (GDB) 7.1
..........
This GDB was configured as "--host=i686-pc-mingw32 --target=arm-none-eabi".
arm-none-eabi-gcc --version
arm-none-eabi-gcc (GCC) 4.5.1
我的 MakeFile:
TRGT = arm-none-eabi-
CC = $(TRGT)gcc
CP = $(TRGT)objcopy
AS = $(TRGT)gcc -x assembler-with-cpp
#AS = $(TRGT)as
LD = $(TRGT)ld
OBJDUMP = $(TRGT)objdump
LD_SCRIPT = main.ld
MCU = arm7tdmi
#DEBUG = stabs
DEBUG = dwarf-2
ASFLAGS = -mcpu=$(MCU) -g$(DEBUG)
LDFLAGS = -T $(LD_SCRIPT)
all: main.elf main.lss
@echo Done!
main.elf : main.o
@echo Linking $<
$(CC) -nostartfiles $(LDFLAGS) $< -o $@
main.o : main.s
@echo Compiling $<
$(AS) -c $(ASFLAGS) $< -o $@
提前感谢您的帮助!
I have a problem with debugging a simple program written with assembler language for ARM7 microcontroller (AT91SAM7S64). I use gcc, gdb and OpenOCD.
My program is loaded to target correctly and works just fine (it blinks a led). But gdb skips through certain source code lines when i invoke 'next' command.
Here is a fragment of source code:
Reset_Handler:
LDR R0, =0x0100
LDR R1, =PIOA_PER
STR R0, [R1]
LDR R1, =PIOA_OER
STR R0, [R1]
uuu:
bl wait;
LDR R1, =PIOA_SODR
STR R0, [R1]
uuu1:
bl wait;
LDR R2, =PIOA_CODR
STR R0, [R2]
b uuu;
@ one second delay
wait:
.............
.............
.end
To get gdb output (see below) i have used "target sim" instead of real target, but rusults are exaclty the same.
(gdb) target sim
Connected to the simulator.
(gdb) load
Loading section .text, size 0xc8 vma 0x100000
Start address 0x100000
Transfer rate: 1600 bits in <1 sec.
(gdb) b Reset_Handler
Breakpoint 1 at 0x100064: file main.s, line 59.
(gdb) run
Starting program: C:\Arm\Projects\Asm/./main.elf
Breakpoint 1, Reset_Handler () at main.s:60
60 LDR R1, =PIOA_PER
(gdb) n
61 STR R0, [R1]
(gdb) n
63 LDR R1, =PIOA_OER
(gdb) n
64 STR R0, [R1]
(gdb) n
uuu () at main.s:66
66 bl wait;
(gdb) n
67 LDR R1, =PIOA_SODR
(gdb) n
68 STR R0, [R1]
(gdb) n <<<<<--------- Here the problem begins
67 LDR R1, =PIOA_SODR
(gdb) n
68 STR R0, [R1]
(gdb) n
67 LDR R1, =PIOA_SODR
(gdb) n
68 STR R0, [R1]
(gdb) stepi <<<<<------ Doing a 'stepi' command allows to pass below 'uuu1' label
uuu1 () at main.s:70
70 bl wait;
(gdb) n
71 LDR R2, =PIOA_CODR
(gdb) n
72 STR R0, [R2]
(gdb) n
73 b uuu;
(gdb) n <<<<<--------- Here the problem begins again
71 LDR R2, =PIOA_CODR
(gdb) n
72 STR R0, [R2]
(gdb) n
73 b uuu;
(gdb) n
71 LDR R2, =PIOA_CODR
(gdb) where
#0 uuu1 () at main.s:71
#1 0x00100084 in uuu1 () at main.s:70
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
It seems like gdb assume 'uuu1' as a separate function and skips it for some reason. If i delete 'uuu1' label the problem disappears. This label is not used anywhere, but gdb behavior looks very strange. I have been trying to find any solution for a long time but with do significant results. Using gcc option '-fomit-frame-pointer' didn't help.
What can i do about it?
Versions of gdb and gcc:
arm-none-eabi-gdb --version
GNU gdb (GDB) 7.1
..........
This GDB was configured as "--host=i686-pc-mingw32 --target=arm-none-eabi".
arm-none-eabi-gcc --version
arm-none-eabi-gcc (GCC) 4.5.1
My MakeFile:
TRGT = arm-none-eabi-
CC = $(TRGT)gcc
CP = $(TRGT)objcopy
AS = $(TRGT)gcc -x assembler-with-cpp
#AS = $(TRGT)as
LD = $(TRGT)ld
OBJDUMP = $(TRGT)objdump
LD_SCRIPT = main.ld
MCU = arm7tdmi
#DEBUG = stabs
DEBUG = dwarf-2
ASFLAGS = -mcpu=$(MCU) -g$(DEBUG)
LDFLAGS = -T $(LD_SCRIPT)
all: main.elf main.lss
@echo Done!
main.elf : main.o
@echo Linking lt;
$(CC) -nostartfiles $(LDFLAGS) lt; -o $@
main.o : main.s
@echo Compiling lt;
$(AS) -c $(ASFLAGS) lt; -o $@
Thanks in advance for any help!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
尝试在有问题的代码段中使用“si”而不是 n。
“n”或多或少是下一个语句,“si”是下一个asm指令。
如果asm片段的调试代码不正确,“si”可能仍然允许您单步执行它,利用在这种情况下“语句”和“汇编器”级别相同的事实。
try using "si" instead of n in the problem piece of code.
"n" is more or less next statement, "si" is next asm instruction.
if the debug code for the piece of asm is not correct, "si" might still allow you to step it, taking advantage of the fact that in this case "statement" and "assembler" level are the same.
通过汇编指令使用
ni
代替next
,使用si
代替step
。Use
ni
instead ofnext
andsi
instead ofstep
through assembler instructions.我知道这有点旧,但您应该尝试将
-O0
标志添加到编译器中。我阻止 gcc 进行任何优化,这可能会导致像您遇到的问题。I know this is a bit old, but you should try to add the
-O0
flag to the compiler. I prevents gcc of doing any optimization, which can lead to problems like the ones you got.