Ich schreibe einen Sparc-Compiler. Einer meiner Testfälle funktioniert einwandfrei, wenn er von der Befehlszeile normal ausgeführt wird, aber segfolds, wenn ich die Ausgabe in eine Datei umleite.Was ist der beste Weg, um einen segfault in meiner SPARC-Assembly zu debuggen?
Ich habe versucht mit GDB, aber es ist schwierig mit der Montage. Wie kann ich etwas herausfinden, das so einfach ist, wie die Baugruppe den Segfault verursacht?
Leider ist GDB wirklich der beste Weg, Probleme auf Maschinenebene in UnixSPARCs zu debuggen, was irgendwie traurig ist.
Die grundlegende Sache zu verstehen ist, dass ein segfault eine Art Ausnahme ist, und Ausnahmen bewirken, dass das Programm in den Debugger einbricht, wenn einer angehängt ist. Sie tun dies, damit Sie den Zustand der Prozessorregister und des Speichers zum Zeitpunkt des Absturzes untersuchen können.
Sie sollten sich das Befehlszählerregister (% ip) ansehen. Dies enthält die Adresse der letzten auszuführenden Anweisung, die die Anweisung ist, die die segfault ausgelöst hat. Es wird eine Lade- oder Speicheroperation sein, so dass Sie sehen können, welches Register seine Quell-/Zielspeicheradresse enthält, und herausfinden, warum diese Adresse schlecht ist (normalerweise ist es NULL oder irgendeine Müllnummer, die keine gültige Adresse ist). Die andere Sache, die Sie tun können, besteht darin, Ihren Prozess zu kompilieren, um einen Kernspeicherabzug auszulösen, wenn er fehlschlägt, der einen Schnappschuss des Status des Programms in dem Moment ausschreiben wird, in dem es als große Datei auf der Festplatte starb. Leider ist das Programm zum Lesen von Core Dumps ... gdb.