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

... komplette Frage anzeigen

2 Antworten

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 :)

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
18.12.2015, 01:06

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)

1

Was möchtest Du wissen?