Hallo Leute, Ich habe folgendes Problem. gdb springt beim Debuggen im Quellcode herum und führt einige Zeilen doppelt aus. Ich kann auch nicht mehr kürzlich belegte Variablen ausgeben. Woran kann das denn liegen ? Hat jemand von euch eine Ahnung. Vielen Dank im voraus. mfg martin
,,einige Zeilen doppelt ausführen'' klingt nach einem Garnicht-Problem, bei dem der optimierte Code für eine C-Quellzeile einfach an verschiedenen Stellen im Objektcode liegt, verschachtelt mit anderem Objektcode. Gewöhn' dich einfach dran, dass sowas passieren kann. > Ich kann auch nicht mehr kürzlich belegte Variablen ausgeben. Woran > kann das denn liegen ? Dass der Compiler diese Variablen an der entsprechenden Stelle bereits wieder wegoptimiert hatte, weil sie gemäß Code-Analyse gar nicht mehr benötigt werden. Manche deiner Variablen werden auf diese Weise gar ganz aus dem Objektcode verschwinden. Da Variablen natürlich nach Möglichkeit in Registern abgelegt werden, werden die Register sofort neu belegt, wenn sie nicht mehr gebraucht werden.
Neulich bin auf ein ähnliches Problem gestossen. Es handelte sich um C++ Code. Zum debuggen hab ich einfach die Optimierung komplett ausgeschaltet. Damit konnte ich das Problem mit den wilden rumspringen umgehen. Ciao, Kai
Das ist aber der völlig falsche Weg. Der Code, der später nicht im "Produkt" verwendet werden soll, braucht auch nicht "debugged" werden. Ohne Optimierung entsteht aber eben solcher! Da können Fehler auftauchen, die bei einer optimierten Variante gar nicht auftreten (können) und Umgekehrt.
@Patrick: Ich glaube nicht das dieser Weg falsch ist, denn den Debugger schmeiss ich zum Fehler suchen an und nicht um meine Software zu verifizieren. Die Verifikation wird auschliesslich durch testen der ferigen Application im Feldversuch vorgenommen. Ciao, Kai
Vielleicht hab ich mich falsch ausgedrückt: Ich meinte natürlich, daß je nach Optimierungsstufe anderer Binärcode hinten rausfällt. Das taugt doch vorne und hinten nicht, um Fehler zu finden...
Hi Patrick, schau Dir mal die Vorgehensweise beim beim Microsoft VC++ Compiler an. Zum debuggen wird eine Debugversion erstellt. Und zum fertigen Release eine dementsprechende Release Version. Microsoft ist vielleicht nicht das beste Beispiel, aber es zeigt das es anscheinend doch geht. Ich persönlich habe damit auch noch keine schlechten Erfahrungen gemacht zumal beim ändern des Optimierungsstatuses bei mir grundsätzlich offentsichtliche Fehler aufgetreten sind. Ich muss Dir aber zustimmen, dass es nicht die perfekte Lösung ist. Dennoch ist es unmöglich (wenn man den Überblick behalten will) eine SW in C++ zu deguggen wenn die Optimierung eingeschaltet ist. Ich wäre auch glücklicher wenn mir jemand eine andere Möglichkeit nennen könnte. Ciao, Kai
Nana, das sind zwei verschiedene Paar Schuhe! Du kannst auch dem gcc sagen, daß er einmal mit und einmal ohne Debuginfos kompilieren soll. Das beeinflusst aber den Ausgeführten Code in keinster Weise. Das was Du da machst aber schon!
Hi Leute, erstmal danke für die vielen Antworten. Hab jetzt wieder was dazu. Ich möchte aber nur mal dumm fragen. Welche Fehler können den entstehen wenn ich die Optimierung wegmache, den Code dann modifiziere und die Optimierung wieder reinmache ? Gruß Martin
Der Compiler könnte Codestellen wegoptimieren, die er ohne Optimierung nicht angefasst hat. Somit ist es möglich, dass sich Dein Programm anders verhält, was natürlich nicht unbedingt sofort sichtbar ist. Wie gesagt ich kenne beim GCC im Zusammenhang mit C++ keine andere Möglichkeit. Ich habe aber auch keine schlechten Erfahrungen bisher gemacht. Probleme bekommst Du nur wenn Du versuchst einen Fehler zu debuggen der ausschliesslich mit Optimierung da ist.
> Probleme bekommst Du nur wenn Du versuchst einen Fehler zu debuggen > der ausschliesslich mit Optimierung da ist. Alles andere als simple Anfängerfehler tendieren aber nach meiner Erfahrung, just in diese Kategorie zu fallen. Der Code ist erstmal ,,offensichtlich korrekt'', und wenn man den nichtoptimierten Code im Einzelschritt (oder geschlossen) abarbeitet, funktioniert alles. Mit Optimierung darf der Compiler aber plötzlich bestimmte Dinge ganz anders umsetzen -- und der kleine versteckte Fehler schlägt zu. Daher ist es auch meine Erfahrung (wie Patricks): lass die Optmierung auf dem Stand, auf dem du sie am Ende haben willst, und gewöhn' dich an die Artefakte beim Debuggen, die sich daraus ergeben.
> ..und gewöhn' dich > an die Artefakte beim Debuggen, die sich daraus ergeben. in der Hoffnung Du verstehst den Code dann noch.
Wenn du ihn nicht verstehst, hast du was falsch gemacht. ;-) Verstehen muss man doch den Sourcecode. Ob der Debugger nun beim Abarbeiten zwischen den Quellzeilen hoch- und runterhüpft oder sie geradlinig abarbeitet, ist doch egal (solange keine volatile-Objekte zwischenzeitlich zugegriffen werden, natürlich). Den generierten Objektcode zu verstehen, ist zwar nett (und oft hilfreich), aber nicht zwingend notwendig.
falsch gemacht hab ich nichts..:-). bestes Beispiel ist mal wieder SimuAvrxx. Da dort, so wie es aussieht noch einige Bugs in der Windows Portierung drin sind muss ich den Code schon verstehen, zumal der nicht von mir ist. Dafür musste ich z.B die Optimierung ausschalten um zu verstehen von Hase in den Pfeffer läuft..:-).
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.