Hallo Forum,
ich habe das folgende nervige Problem beim Debuggen mit Crossstudio für
ARM: die Speicheradressen der Befehle im optimierten Code sind nicht in
der richtigen Reihenfolge. Das führt dazu, das man sich nicht sicher
sein kann, das ein Breakpoint auch wirklich zuschlägt, wenn er das
sollte.
Ich weiss, das ist im optimiertem Code immer ein Problem, aber wenn
wenigstens der Code in der richtigen Reihenfolge stehen würde, das
könnte schon helfen. Dann geht zwar in einigen Fällen der Zusammenhang
zwischen C-Code und Assembler verloren, aber so isses auch nicht schön. 1 | btmp[1]+=ActRecord;
| 2 | 00011430 4B2F ldr r3, [pc, #0x0BC]
| 3 | 00011434 781B ldrb r3, [r3, #0x00]
| 4 | 0001143A 3330 adds r3, #0x30
| 5 | 0001143C F88D3006 strb.w r3, [sp, #+0x006]
| 6 | SEND_BLOCK(btmp,3);
| 7 | 00011432 2103 movs r1, #0x03
| 8 | 00011436 F10D0005 add.w r0, sp, #0x00000005
| 9 | 00011440 4B2E ldr r3, [pc, #0x0B8]
| 10 | 00011442 4798 blx r3
| 11 | 00011444 F0100FFF tst r0, #0x000000FF
| 12 | 00011448 D14A bne 0x000114E0
| 13 | 0001144A E046 b 0x000114DA
|
Im Bsp ist die Adresse 32 nach der 3C. Ich verwende den GCC zum
kompilieren und Crossworks nur zum Debuggen.
Kann man dem Crossworks das irgendwie abgewöhnen?
(und bitte nicht so dumme Kommentare wie: "Dann debug doch im
unoptimiertem Code")
Das dürfte ein Fehler im Debugger sein, mit optimiertem oder nicht
optimiertem Code kann das nichts zu tun haben.
Das ist Thumb-Code, nicht wahr?
Vielleicht versteht ja Crossworks auch nur die Debuginfos nicht, die
Dein gcc erzeugt.
> Ich verwende den GCC zum
> kompilieren und Crossworks nur zum Debuggen.
Warum? Was nutzt denn Crossworks als Compiler, ist das nicht auch gcc?
> Das ist Thumb-Code, nicht wahr?
Ja, Thumb-Mode
> Warum? Was nutzt denn Crossworks als Compiler, ist das nicht auch gcc?
Crossworks hat den GCC, aber 1. nicht in der aktuellen Version und 2.
passt das nicht in meine Toolchain. Das kann ich nicht umstellen. Da
hängt noch viel mehr dran.
Im nicht-optimierten Code funktioniert das super - alles linear und
aufgeräumt. Nur leider passt der unoptimierte Code nich mehr in Flash.
Probier mal, die einzelnen Optimierungsschritte selektiv abzuschalten,
d.h. mit -fno-... anzugeben:
http://gcc.gnu.org/onlinedocs/gcc-4.4.4/gcc/Optimize-Options.html#Optimize-Options
Gute Kandidaten wären solche wie -fno-reorder-blocks und
-fno-schedule-insns. Nach der -O... Option.
Nun, wenn man sich den von Dir geposteten Code genau ansieht, dann
scheint die Optimierung die beiden C-Code-Zeilen
btmp[1]+=ActRecord;
SEND_BLOCK(btmp,3);
zu einem Codeblock übersetzt zu haben, bei denen abwechselnd
Instruktionen für die eine und für die andere Codezeile zuständig sind.
Der Debugger scheint aber die Instruktionen auf die zugehörigen
Codezeilen zurückzuverteilen.
Bringt man das ganze von Hand in die richtige Reihenfolge, kommt das
hier 'raus:
1 | * 00011430 4B2F ldr r3, [pc, #0x0BC]
| 2 | # 00011432 2103 movs r1, #0x03
| 3 | * 00011434 781B ldrb r3, [r3, #0x00]
| 4 | # 00011436 F10D0005 add.w r0, sp, #0x00000005
| 5 | * 0001143A 3330 adds r3, #0x30
| 6 | * 0001143C F88D3006 strb.w r3, [sp, #+0x006]
| 7 | # 00011440 4B2E ldr r3, [pc, #0x0B8]
| 8 | # 00011442 4798 blx r3
| 9 | # 00011444 F0100FFF tst r0, #0x000000FF
| 10 | # 00011448 D14A bne 0x000114E0
| 11 | # 0001144A E046 b 0x000114DA
|
(die Zeilen habe ich durch vorangestellte * bzw. # als zu den
unterschiedlichen C-Codezeilen gehörig gekennzeichnet)
Wenn Du Deinen separat genutzten gcc dazu instruierst, ein Listing-File
zu erzeugen, sieht das darin denn anders aus?
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
|
Thread beobachten
Seitenaufteilung abschalten