Hallo,
ich habe ein Problem mit GDB.
Ich habe es zum Laufen gekriegt, sowohl Kommandozeile als auch mit
Insight nur beim Singlestep über diese Zeile:
for (j = 0; j < 500000; j++ )
{}
hängt er jedesmal. Singlestep über Einzelbefehle geht.
Habe auch schon
for (j = 0; j < 500000; j++ );
probiert, geht auch nicht.
Optimization ist auf 0.
Umgebung ist WinXP, Yagarto, OpenOCD, geht aber alles problemlos
Kann jemand helfen?
Danke
Martin
Hallo Christian,
vielen Dank für Deine Antwort.
- Ja, j ist volatile
- Die Schleife wird aber sicher benutzt, hier das gesamte Programm
(Hauptschleife):
while (1) {
for (j = 0; j < 500000; j++ )
{} // wait 500 msec
IO0SET = 0x00000400; // red led 1 off
IO0CLR = 0x00000800; // red led 2 on
for (j = 0; j < 500000; j++ )
{} // wait 500 msec
IO0CLR = 0x00000400; // red led 1 on
IO0SET = 0x00000800; // red led 2 off
}
Zwei LEDs blinken im Wechsel, ich sehe ein Blinken, die Endwerte für j
werden benutzt.
- Wenn ich volatile entferne, ist die Situation dieselbe wie vorher.
....
so, jetzt habe ich noch ein paar Sachen probiert, auf deinen Kommentar
hin "sinnlose Schleifen".
Wenn die Schleife so aussieht:
for (j = 0; j < 500000; j++ )
{
nop ();
}
dann wechselt Insight mit jedem Singlestep zwischen der for- und der
nop-Zeile. Allerdings hängt er da natürlich ewig fest. (aber das
Programm Insight / GDB) hängt nicht mehr)
Und mit diesem hier:
void wait (void)
{
int j;
for (j = 0; j < 500000; j++ )
{
nop ();
}
}
kann man dann auch finish machen bzw in der Hauptschleife mit next über
wait drüberlaufen.
Bleibt noch die Frage, was an dem leeren Schleifenkörper nicht gefällt,
nur so, um was dazuzulernen.
Vielen Dank, falls es jemand weiß
Gruß
Martin
Das ist dann aber kein c Standard oder?
Bezug nehmend auf das da:
http://homepage.univie.ac.at/Heinz.Kabelka/edv-ueb/variabl.htm
Hm oder, int ist Compiler abhängig...
Na gut, ich benutze da immer eindeutigere Typen, wie "short" wenn ich
2Byte int's meine und "long int" wenns um 4Byte geht.
Sorry^^
Martin M. schrieb:
> Bleibt noch die Frage, was an dem leeren Schleifenkörper nicht gefällt,> nur so, um was dazuzulernen.
Er steppt Dein Programm dann so lange, bis es eine andere
Quellcode-Zeile erreicht. Da der Schleifenkörper leer ist, bleibt es
500000mal auf derselben Zeile, bevor es die nächste erreicht, und das
dauert nun mal.
Daniel R. schrieb:
> Das ist dann aber kein c Standard oder?
Schon, doch.
> Bezug nehmend auf das da:> http://homepage.univie.ac.at/Heinz.Kabelka/edv-ueb/variabl.htm
Und das ist Müll. Solche Bereiche schreibt der C-Standard nicht vor,
aber die gezeigten entsprechen dem Standard (sind eine der vielen
Möglichkeiten).
> Hm oder, int ist Compiler abhängig...> Na gut, ich benutze da immer eindeutigere Typen, wie "short" wenn ich> 2Byte int's meine und "long int" wenns um 4Byte geht.
Das ist keineswegs eindeutiger, mit short und long bist Du genauso nass
(compilerabhängig). Willst Du genau 8 Bits haben, nimm int8_t und für 2
Bytes int16_t. Das hat die Evolution in ihrer unendlichen Weisheit in
C99 extra dafür standardisiert.
Hallo,
@ Christian:
ja, ARM7, hatte ich eingangs vergessen
@ Hazeh:
Ich verstand single step so, dass er (=GDB / Insight) die Zeile einmal
ausführt und dann wartet. Gesehen habe ich aber, dass er gar nicht mehr
reagiert, musste manchmal mehrmals Stop klicken, bevor ich ihn resetet
gekriegt habe.
Aber es ist natürlich schon uneindeutig, was hier einmal ausführen
heißen soll, einmal j erhöhen oder einmal bis zum Grenzwert von j. Wenn
letzeres, sollte er dass doch aber ohne permanenten Eingriff des
Debuggers tun, also durch bis zur nächsten Zeile laufen (mit voller
Controllergeschwindigkeit)?
Gruß
Martin
Das, was du willst, ist im GDB das Kommando "until". Aber auch
hier bleibt dem GDB nichts anderes übrig, als immer wieder die
Applikation anzuhalten.
Besser kommst du, wenn du gleich einen (ggf. temporären) Breakpoint
dahinter setzt (denn im Gegensatz zum Debugger weißt du genau,
dass der nächste auszuführende Code immer direkt hinter der Schleife
kommt) und dann bis dorthin in Echtzeit laufen lässt.
> Ich verstand single step so, dass er (=GDB / Insight) die Zeile einmal> ausführt und dann wartet.
Die interne Logik des gdb ist aber so, dass er im Single Step
Einzelschrittausführung macht, bis sich die Zeilennummer ändert (= der
Programmzähler die Adresse einer anderen Zeile enthält). Das geschieht
also nicht in Echtzeit. Deshalb kannst Du in Deinem Fall (5000000 mal
dieselbe Zeile) warten, bist Du (fast) schwarz bist.
Um in Echtzeit auszuführen, musst Du, wie Jörg schon schrieb, einen
Breakpoint setzen und dann "continue" machen.
Hallo,
und vielen Dank für die Beiträge.
Ich denke mein Problem ist gelöst und ich weiß jetzt worauf ich beim
Arbeiten mit GDB/Insight achten muß.
Gruß
Martin
Eine eigene Frage?
Dieser Thread ist über 17 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
