Rust: Debug-Darstellung von Merkmalsobjekten hinzufügen

Was wäre eine Debug-Darstellung einer Eigenschaft? Ich stelle mir ein Trait als eine reine Kompilierzeit-Entität vor, die gelöscht wird, wenn Sie zur Laufzeit gelangen.

@jdm Ist dies speziell für @Trait- Objekte (in diesem Fall stimme ich zu, dass wir die Vtable dem Debugger zugänglich machen möchten?) Wenn ja, werde ich den Fehlertitel und die Beschreibung klären.

Ja, ich denke, es wäre in Ordnung, dies auf Merkmalsobjekte (der Sorte ~ und @) auszudehnen.

Gemäß middle/trans/debuginfo.rs : cx.sess.span_note(span, "debuginfo for trait NYI");

dh dies ist immer noch gültig, richtig gekennzeichnet und mit Meilenstein versehen, 2013-06-19.

Triage-Besuch; auf @michaelwoerister verweisen.

Triage-Besuch; auf @michaelwoerister verweisen.

Es ist immer noch NYI, sollte aber diesen Monat irgendwann in Angriff genommen werden.

Aktualisieren:

Ab PR #9168 gibt es einige grundlegende Unterstützung für Merkmalsobjekte. Ein Merkmalsobjektzeiger wird als Struktur mit der richtigen Größe (zwei Zeiger) und dem richtigen Namen ({sigil}{Mänderbarkeit}{Merkmalsname}) beschrieben und im richtigen Namensraum platziert. Das Innere dieses "fetten Zeigers" wird noch nicht weiter beschrieben. Was fehlt, ist die Beschreibung der Methoden des Merkmals. Ich weiß nicht genug darüber, wie sie tatsächlich umgesetzt werden, um viel darüber zu sagen.

Nicht 1.0, aber hoch

@michaelwoerister : Das neue vtable-Layout ist übrigens [drop_glue, method, method2, method3, ...] . Ich bin mir sicher, dass sich dies in Zukunft irgendwie ändern wird, wenn Supertrait-Methoden für Trait-Objekte aufrufbar werden.

Dies ist mit DST komplizierter geworden, da Sie Objekte wie Fat<Trait> wobei Fat eine DST-Struktur ist. Der Stub-Code für Trait-Objekte ist etwas kaputter geworden, aber ich möchte ihn nicht reparieren, da es sich nur um einen Stub handelt. Ich habe dort ein FIXME hinterlassen.

Triage Bump: unsicher, wie der Status heute ist.

muss noch tun

Wir könnten Folgendes tun:
(1) Erstellen Sie eine Typbeschreibung für jedes Merkmal, das die von ihm definierten Methoden enthält. Da es im DWARF-Standard noch keine Eigenschaften gibt, wäre die Verwendung von DW_AT_interface am sinnvollsten. Aber vielleicht ist die Verwendung von DW_AT_struct mit unseren C-orientierten Debuggern kompatibel.

(2) Beschreiben Sie Merkmalszeiger ( &Trait et al.) als Tupel vom Typ (*(), *OpaqueVTable<Trait>) .

(3) Implementieren Sie benutzerdefinierte GDB/LLDB-Befehle in Python, die bei einem dicken Zeiger den Zeigerwert und die Typinformationen verwenden, um die vtable zu drucken.

Das ist nicht perfekt, aber mit den derzeit verfügbaren Mitteln machbar. Die Symbolnamen der Funktionen, auf die die vtable zeigt, sollten auch den tatsächlichen Laufzeittyp des Merkmalsobjekts angeben.

Nur in Builds mit Debug-Informationen (dh keine Release-Builds) und nur in sehr geringem Umfang

Triage: muss noch gemacht werden. cc @Manishearth @tromey P-low

Dies ist jetzt sowohl P-low als auch P-medium

Entfernen von P-Medium

Ich habe mir das vor kurzem ein wenig angesehen. Was ich hoffe zu tun ist:

• Geben Sie einen DWARF aus, der jede ausgegebene vtable beschreibt. Dies würde den Typ der vtable beschreiben (als Struktur von Zeigern auf eine Funktion), die Position der vtable und den konkreten Typ, der durch diese vtable repräsentiert wird (vielleicht kann DW_AT_containing_type dafür umfunktioniert werden).
• Beschreiben Sie weiter das Innere eines Merkmalsobjektzeigers. Derzeit denke ich, dass dies über einen kleinen Hack erfolgen muss, denn während DWARF eine Möglichkeit beschreibt, den vtable-Slot einer bestimmten Funktion zu berechnen, scheint es keine Möglichkeit zu geben, anzugeben, dass "dieses Mitglied des Objekts die vtable" ist. .

Dann kann ein Debugger Folgendes tun, um einen Merkmalsobjektzeiger zu drucken: Wenn der Typ eines Werts eine Vtabelle hat, holen Sie die Vtabelle von der untergeordneten, suchen Sie die Adresse der Vtabelle im DWARF, um den Vtabellentyp zu finden, und verwenden Sie dann den konkreten Typ, um den Nutzlastzeiger dekodieren.

Ich arbeite daran. Ich habe einen LLVM-Patch, damit rustc eine kleine DWARF-Erweiterung (die DW_AT_containing_type ) Idee ausgeben kann; ein rustc-Patch, um die Grundlagen der vtable auszugeben (Adresse und enthaltener Typ, nicht die Methoden), und den größten Teil eines gdb-Patches, um alles zu lesen und print zum Laufen zu bringen.

Erster Erfolg heute:

(gdb) p tu
$1 = traitobjtest::&T {pointer: 0x7fffffffe047 "\027\070\340\377\377\377\177\000", vtable: 0x5555555c34e8 <vtable> "\360\253UUUU\000"}
(gdb) p *tu
$2 = 23

Aufregend!

Der LLVM-Patch ist hier: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20171016/495458.html

Wechsel zum Phabrikator; Vielleicht ist es dort auch einfacher zu folgen: https://reviews.llvm.org/D39503

gdb-Patch zum Drucken von Trait-Objekten ist hier: https://sourceware.org/ml/gdb-patches/2017-11/msg00289.html

Teil 2 kann durch die Beschreibung der Felder der vtable erfolgen. Ich habe mir die Rustc-Bits noch nicht angeschaut, um zu sehen, wie schwierig das ist. Die info vtbl Bits in gdb sind nicht schwer, meistens virtualisieren sie nur den vorhandenen Befehl ein bisschen mehr. Mit korrekten Feldnamen scheint es auch einfach zu sein, Methodenaufrufe für Merkmalsobjekte zu implementieren.

Version 2 des gdb-Patches ist hier: https://sourceware.org/ml/gdb-patches/2017-11/msg00369.html

Der gdb-Patch ist jetzt drin, aber ich denke, dieses Problem sollte offen gelassen werden, da noch die andere vtable-Aufgabe zu implementieren ist.

@tromey erfordert die "vtable-Aufgabe" gdb-Änderungen oder nur rustc-Änderungen?

@tromey erfordert die "vtable-Aufgabe" gdb-Änderungen oder nur rustc-Änderungen?

Im Idealfall würde es meiner Meinung nach beides erfordern; Aber nur die rustikalen Teile zu machen, wäre ein guter Anfang (und das muss sowieso zuerst kommen). Die Aufgabe hier besteht darin, rustc eine vollständige Beschreibung der vtable im DWARF ausgeben zu lassen, also den Typ und den Namen jedes Members.