Reputation: 51
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 $<
$(CC) -nostartfiles $(LDFLAGS) $< -o $@
main.o : main.s
@echo Compiling $<
$(AS) -c $(ASFLAGS) $< -o $@
Thanks in advance for any help!
Upvotes: 5
Views: 2663
Reputation: 1754
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.
Upvotes: 0
Reputation: 3466
Use ni
instead of next
and si
instead of step
through assembler instructions.
Upvotes: 0
Reputation: 26358
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.
Upvotes: 2