Frage von tippa2, 36

Warum verschiebt sich der break point bei gdb nach dem Hinzufügen von debugging infos?

Hallo, habe eine Frage zum Debuggen mit gdb. Quellcode der Datei kann man im zweiten Bild sehen. Programmieren etc. ist totales Neuland für mich. Habe ne binärdatei erstellt und diese mit gdb debuggt und einen break point bei main gesetzt. Nun hält gdb bei 0x0804837a der Speicheradresse an. Nachem ich debugging infos hinzugefügt habe (gcc -g) habe ich wieder einen break point bei main gesetz nun hält er aber bei der speicheradresse0x08048384, also später an. Kann mir jemand erklären warum dies so ist?

Antwort
von TeeTier, 21

Weil GCC mit "-g" anderen Code erzeugt, der dann selbstverständlich eine andere Adresse besitzt.

Anstatt "break *0xabcdef" kannst du doch einfach "break main" schreiben. Dann musst du dir um Adressen keine Sorgen machen, wenn sowieso Debugging-Symbole vorhanden sind, und du relative offsets (also Funktionsnamen) angibst.

GDB lässt sich übrigens super skripten, und du könntest dir dafür ein kleines Startskript basteln, was dir automatisch alle Breakpoints dynamisch hinzufügt.

Eigentlich muss man sich ja nur mit absoluten Breakpoint-Adressen beschäftigen, wenn man die CPU-Instruktionen einzeln durchsteppen will, und die zu untersuchende Binary keine Debugging-Symbole enthält, bzw. gestrippt ist.

Jede Änderung an der Binary - vor allem das Neukompilieren und Hinzufügen von Debug-Infos - verändert diese, und damit auch die Adressen. Zumindest ist die Wahrscheinlichkeit dazu sehr hoch.

Kommentar von tippa2 ,

schade, dass die Bilder so klein sind. Also wenn ich disassemble werden mir die selben speicheradressen mit gleichen Instruktionen angezeigt, ob mit oder ohne info, ist genau das selbe bild. aber gdb hält einmal bei dem 4ten speicher an (ohne info) (Operation and) und mit info beim 7ten (Operation mov). Schon mal Entschuldigung für meine Ausdrucksweise, bin noch total neu in diesem Bereich, aber bereit zu lernen. Kann es sein, dass gdb "klüger" wird durch die info einspeisung und deshalb erst stoppt, wo int i definiert wird. (aber ohne info schon vorher anhält)

Kommentar von TeeTier ,

Wenn GCC Optimierungen vor nimmt, ist es am Ende nicht mehr Eindeutig, welche Quellcode-Aktion auf welche CPU-Instruktion abzubilden ist.

Deshalb kompiliert man zum Debuggen meist mit "-O0 -g". Damit werden Optimierungen deaktiviert, und der Quelltext stupide ohne jegliche "Verbesserungen" übersetzt.

Versuch es mal mit "-O0", und zwar einmal mit und einmal ohne Debugging-Infos. :)

Antwort
von tippa2, 11

Hey tut mir leid, dass ich jetzt erst antworte. hatte vorher keine zeit deinen tipp zu befolgen. ich habe es so gemacht, wie du gesagt hast, aber es ist immer noch das selbe ergebnis. hmmm....vielleicht kann man es ja auf diesem screenshot bisschen besser erkennen :) ich hoffe du antwortest nochmal :)

Keine passende Antwort gefunden?

Fragen Sie die Community

Weitere Fragen mit Antworten