Wie erhalte ich mehr Informationen über einen Seg-Fehler?

Das Buch Assembly Language Schritt für Schritt bietet den folgenden Code als Sandbox:Wie erhalte ich mehr Informationen über einen Seg-Fehler?

section .data 
section .text 

global _start     

_start: 

    nop 
    //insert sandbox code here 
    nop

Jedes Beispiel, das ich in dem Raum für Sandbox enthalten ist ein Segmentierungsfehler erzeugt wird. Zum Beispiel das Hinzufügen dieser Code:

mov ax, 067FEh 
mov bx, ax 
mov cl, bh 
mov ch, bl

Dann Kompilieren mit:

nasm -f macho sandbox.asm 
ld -o sandbox -e _start sandbox.o

schafft eine seg Fehler, wenn ich es auf meinem OS/X laufen. Gibt es eine Möglichkeit, mehr Informationen darüber zu erhalten, was den Segmentierungsfehler verursacht?

Quelle

2016-03-22 Leahcim

Das Ausführen unter einem Debugger wäre ein guter Anfang. In diesem Fall liegt der Grund für den Absturz wahrscheinlich darin, dass die CPU nach dem Ausführen des letzten NOP-Befehls in Ihrem Programm weiterhin ausführt, welche Befehle sich im Speicher befinden, die sich im Speicher befinden. –

Wenn ich es in einem Debugger starte, wird es automatisch mit einem Seg Fehler beendet. – Leahcim

Idealerweise würden Sie hoffen, dass sich das Verhalten Ihres Programms nicht ändert, wenn es unter einem Debugger ausgeführt wird. Es sollte Ihnen zumindest sagen, wo Ihr Programm abgestürzt ist und welcher Befehl den Absturz verursacht hat. –

Das Problem, das Sie haben, besteht darin, dass Sie ein Programm erstellt haben, das nach dem Ende des von Ihnen geschriebenen Codes ausgeführt wird.

Wenn Ihr Programm ausgeführt wird, gibt der Lader eine jmp an Ihre _start aus. Ihr Code läuft dann, aber Sie haben nichts, um am Ende zum Betriebssystem zurückzukehren, also wird es einfach weiterlaufen und alle Bytes ausführen, die sich nach Ihrem Code im RAM befinden.

Die einfachste Lösung wäre, den Code ordnungsgemäß zu beenden. Zum Beispiel:

mov eax, 0x1    ; system call number for exit 
sub esp, 4    ; OS X system calls needs "extra space" on stack 
int 0x80

Da Sie keine tatsächliche Ausgabe generiert, müßten Sie mit einem Debugger Schritt durch, um zu sehen, was los ist. Nach dem Kompilieren können Sie lldb verwenden, um durchzugehen.

lldb ./sandbox 
image dump sections

Notieren Sie die Adresse aufgelistet, die vom Typ code für die ausführbare Datei (nicht dyld). Es wird wahrscheinlich 0x0000000000001fe6 sein. Fortsetzung innerhalb LLDB:

b s -a 0x0000000000001fe6 
run 
register read 
step 
register read 
step 
register read

An diesem Punkt sollten Sie vorbei an den NOPs sein und Dinge zu verändern, die in den Registern sehen. Habe Spaß!

Quelle

2016-03-23 00:28:45

Ich habe nach den Move-Anweisungen ein 'ret' hinzugefügt. Gleiches Ergebnis. Ich habe das 'ret' nach dem finalen' nop' und dem gleichen Ergebnis bewegt. – Leahcim

Entschuldigung. Ich hatte eine Minute lang den Kopf in der alten 16/32 Bit Real Mode Welt. Dies sollte es für Sie lösen. –

Vielen Dank für die zusätzlichen Informationen (ich wusste nicht über lldb Werkzeug, ich war mit gdb). Die für Typcode aufgelistete Adresse ist '0x0000000000001fe9'. Wenn ich 'b s -a 0x0000000000001fe99' führe, gibt es mir eine Warnung 'nicht in der Lage, Haltepunkt zu irgendwelchen tatsächlichen Positionen aufzulösen'. Nach 'run' existiert es mit status = 1 und dann' register read' sagt 'error invalid thread' – Leahcim

Wie erhalte ich mehr Informationen über einen Seg-Fehler?

Antwort

Verwandte Themen