Wie GDB Befehl nach Breakpoint wiederherstellen

Question

Ich habe gelesen, dass GDB eine int 3 (Opcode CC) an der gewünschten Adresse in den Zielprogrammspeicher legt.

Mit dieser Operation wird ein Befehl (1 Byte) im Programmspeicher gelöscht. Meine Frage ist: Wie und wann ersetzt GDB den ursprünglichen Opcode, wenn das Programm fortfährt?

Wenn ich Disassemble in GDB eingeben, sehe ich nicht CC Opcode. Ist das, weil GDB weiß, dass er der CC ist? Gibt es eine Möglichkeit, eine rohe Disassemblierung durchzuführen, um genau zu sehen, welche Opcodes in diesem Moment im Speicher geladen sind?

Answer 1

Wie und wann ersetzt GDB den ursprünglichen Opcode, wenn das Programm fortgesetzt wird?

Ich benutze dies als eine Interview-Frage ;-)

Unter Linux, vorbei an dem Haltepunkt fortzusetzen, wird 0xCC mit der ursprünglichen Anweisung ersetzt und ptrace(PTRACE_SINGLESTEP, ...) erfolgt. Wenn der Thread bei der nächsten Anweisung anhält, wird der ursprüngliche Code erneut durch den Opcode 0xCC ersetzt (um den Breakpoint wiederherzustellen), und der Thread wurde auf seinem fröhlichen Weg fortgesetzt.

auf x86-Plattformen, die nicht PTRACE_SINGLESTEP haben, wird trap flag über ptrace(PTRACE_SETREGS, ...) in EFLAGS gesetzt, und der Faden wird fortgesetzt. Das Trap-Flag bewirkt, dass der Thread sofort wieder stoppt (bei der nächsten Anweisung, so wie PTRACE_SINGLESTEP).

Wenn ich Disassemble in GDB eingeben, sehe ich nicht CC Opcode. Ist das, weil GDB weiß, dass er der CC ist?

Korrekt. Ein Programm könnte seinen eigenen Befehlsstrom untersuchen und drucken, und Sie können den Haltepunkt 0xCC auf diese Weise beobachten.

Gibt es eine Möglichkeit, eine rohe Disassemblierung durchzuführen, um genau zu sehen, welche Opcodes in diesem Moment im Speicher geladen sind?

Ich glaube nicht, dass es gibt. Sie können (gdb) set debug infrun verwenden, um zu beobachten, was GDB mit dem minderwertigen (debugged) Prozess macht.

Was ich nicht verstehe, ist die genaue Rolle von SIGTRAP. Wer sendet/empfängt dieses Signal? Der Debugger oder das Zielprogramm?

Weder: nach PTRACE_ATTACH, die Kernel die untere stoppt, benachrichtigt dann den Debugger, der es getan hat, durch wait Rückkehr des Debuggers zu machen.

Ich sehe eine Wartezeit (NULL) nach dem Ptrace-Attach. Was bedeutet dieses Warten?

Siehe die obige Erklärung.

Gewindespezifische Haltepunkte?

für einen Thread-spezifischen Breakpoint, fügt der Debugger einen Prozess weiten Breakpoint (via 0xCC Opcode), dann einfach sofort jeden Faden wieder aufnimmt, die den Haltepunkt trifft, es sei denn, der Thread die spezifische ist, dass Sie aufhören wollte .