Ich habe ein LLVM-Targeting-Frontend erstellt, das IR erzeugt. In der Folge und völlig zu erwartend ist die IR-Ausgabe in einigen Fällen falsch (wie in, es scheint richtig, aber das resultierende Programm stürzt ab, wenn es ausgeführt wird). Ich habe jedoch nicht viele nützliche Werkzeuge gefunden, um damit umzugehen.
Ich habe versucht, lli zu verwenden, aber die Ausgabe der Fehlermeldung ist spektakulär nicht hilfreich (wenn man annehmen würde, dass ein Interpreter sehr genaue Fehlerdetails angeben kann).
Ich habe versucht, den IR in den C-Code zu konvertieren und diesen dann mit Visual Studio zu debuggen, aber es scheint, dass diese Funktionalität aus LLVM entfernt wurde.
Ich habe auch über den Umgang mit GDB nachgedacht. Wie auch immer, das DWARF-Debug-Informationsformat ist ziemlich spezifisch für einige existierende Sprachen und zusätzlich ist die Quelle, die ich mit meinem Frontend übersetzt, korrekt, es ist die erzeugte IR, die falsch ist, also Debug-Symbole für die ursprüngliche Quelle würden nicht bin nicht zu hilfreich - zum Beispiel müsste ich die Werte einer Reihe von Zwischenregisterwerten sehen, die keiner Quellvariablen oder einem Haltepunkt in vom Compiler generierten Funktionen entsprechen.
Welche Tools und Techniken gibt es, um die LLVM-IR-Ausgabe zu debuggen?
Ich bin mir nicht sicher, ob ich dein Problem vollständig verstehe. Sagen Sie, dass Ihr Compiler (von Sprache X zu LLVM IR) eine falsche Ausgabe (falsche LLVM IR) produziert und Sie nicht sicher sind, wie Sie es debuggen? Mit anderen Worten, es gibt zwei Möglichkeiten:
Ich nehme an, dass es (1) ist, worüber du sprichst (weil das die Frage war, bevor du sie aktualisiert hast)
Dies wäre dann kein LLVM-spezifisches Problem. Angenommen, Sie schreiben einen Compiler von der Sprache X in den nativen Code. Der erzeugte native Code ist falsch - wie debuggen Sie das Problem? Nun, Sie debuggen natürlich Ihren Compiler. Sie versuchen, den letzten Ort zu finden, an dem das Verständnis des Compilers für die Eingabe korrekt war, oder der erste Ort, an dem es falsch war. Wie Sie das tun, hängt sehr von der Architektur Ihres Compilers ab. Was jedoch sehr hilfreich ist, ist eine druckbare Darstellung anderer Zwischenebenen in Ihrem Compiler.
Zum Beispiel kann Clang (das LLVM IR aus C, C ++ und Objective C erzeugt) seinen vollständigen AST ablegen. Wenn man sich die AST für den falschen Code ansieht, kann man den Compiler in zwei Hälften schneiden, um festzustellen, ob das Problem im Front-End (C-Quelle - & gt; AST) oder Code-Gen (AST - & gt; LLVM IR) liegt. Das LLVM-Backend (kompiliert LLVM IR zu nativem Code) hat auch ein paar Zwischenschichten (vor allem SelectionDAG und MIs), die zum Zwecke des Debuggens untersucht werden können. Dies sind nur Beispiele für andere bestehende Compiler, YMMV mit Ihren.
Will Diez hat beschrieben, wie er das umgesetzt hat:
Ссылка
Hallo alle,
Für meine eigenen Zwecke habe ich einen Pass geschrieben, der genau das tut, was Sie alle sind Beschreibung: Hinzufügen von Debug-Metadaten zu LLVM IR.
Als Pass musste es das Problem angehen: "Diese Datei muss existieren irgendwo auf der CD, damit gdb es finden kann ", womit ich mein Dumping gelöst habe auf / tmp / irgendwo. Keine gute Lösung (wer löscht diese?) Aber hat gut genug funktioniert.
Ein weiteres interessantes Thema ist die Koexistenz mit einem vorhandenen Debug Metadaten, die nützlich sein können, um ein IR gleichzeitig zu debuggen Inline mit der C-Quelle für Pässe im Instrumentierungsstil transformieren wie SAFECode, ASan / TSan.
Schnelles Beispiel:
%Vor%Der Durchlauf selbst ist ziemlich einfach - das schwierige Problem, das er löst, ist die IR auf die Festplatte ausstrahlen und darüber nachdenken, worauf Instruktion * steht welche Linie, die wirklich kein Problem sein sollte, wenn es richtig gemacht wird LLVM. Auf Wunsch kann ich den Code natürlich auf Anfrage zur Verfügung stellen.
Kurz gesagt, es schien gut für mich zu funktionieren und es richtig gemacht zu haben LLVM selbst wäre großartig!
Leider scheint der Code nicht verfügbar zu sein.
Tags und Links llvm