J'ai un problème avec le débogage d'un programme simple écrit avec le langage assembleur pour le microcontrôleur ARM7 (AT91SAM7S64). J'utilise gcc, gdb et OpenOCD. Mon programme est chargé pour cibler correctement et fonctionne très bien (il clignote une led). Mais gdb ignore certaines lignes de code source lorsque j'appelle la commande 'next'.Gdb ignore les lignes de code source pendant le débogage du programme assembleur pour le microcontrôleur ARM7
Voici un fragment de code source:
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
Pour obtenir une sortie de gdb (voir ci-dessous) je l'ai utilisé "cible sim" au lieu de la vraie cible, mais rusults sont exaclty les mêmes.
(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)
Il semble que gdb considère 'uuu1' comme une fonction séparée et l'ignore pour une raison quelconque. Si je supprime l'étiquette 'uuu1' le problème disparaît. Cette étiquette n'est utilisée nulle part, mais le comportement de gdb est très étrange. J'essaie de trouver une solution depuis longtemps mais avec des résultats significatifs. L'utilisation de l'option gcc '-fomit-frame-pointer' n'a pas aidé. Que puis-je faire à ce sujet?
versions de gdb et 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
Mon 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 [email protected]
main.o : main.s
@echo Compiling $<
$(AS) -c $(ASFLAGS) $< -o [email protected]
Merci à l'avance pour toute aide!
Oui, cela fonctionne (voir mes commentaires dans le journal gdb ci-dessus). Mais fonctionne comme un «pas en avant» au lieu de «passer». Je voudrais que gdb surpasse la procédure 'wait' de la même façon que sur la ligne 66. Je prévois d'utiliser gdb avec Eclipse et c'est très ennuyeux pour moi. – Romario
Pourquoi "déboguer le code pour le morceau d'asm" pourrait ne pas être correct? Peut-être qu'il y a un argument de compatibilité "magique" pour gdb ou gcc? – Romario
Bugs dans gcc je suppose. Les informations de débogage ne sont pas synchronisées avec les lignes. Peut-être que vous pouvez essayer de forcer le nain –