Rust: Ajouter une représentation de débogage des objets trait

Quelle serait une représentation de débogage d'un trait ? Je pense à un trait comme à une entité purement compilée qui est effacée au moment où vous arrivez à l'exécution.

@jdm Est-ce spécifiquement pour les objets @Trait (auquel cas, oui, je suis d'accord que nous voudrions exposer la vtable au débogueur ?) Si c'est le cas, je vais clarifier le titre et la description du bogue.

Oui, je pense que définir cela pour couvrir les objets de trait (de la variété ~ et @) serait bien.

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

c'est-à-dire qu'il est toujours valide, correctement étiqueté et jalonné, 2013-06-19.

Visite de triage; s'en remettant à @michaelwoerister.

Visite de triage; s'en remettant à @michaelwoerister.

Il s'agit toujours de la JNI mais devrait être abordé ce mois-ci.

Mettre à jour:

Depuis le PR #9168, il existe une prise en charge de base des objets trait. Un pointeur d'objet trait est décrit comme une structure avec la taille correcte (deux pointeurs) et le nom correct ({sigil}{mutability}{trait name}) et est placé dans l'espace de noms correct. L'intérieur de ce « gros pointeur » n'est pas encore décrit plus avant. Ce qui manque, c'est la description des méthodes du trait. Je ne sais pas assez comment ils sont réellement mis en œuvre pour en dire beaucoup à ce sujet.

Pas 1,0, mais élevé

@michaelwoerister : Au fait, la nouvelle disposition de la table virtuelle est [drop_glue, method, method2, method3, ...] . Je suis sûr que cela changera d'une manière ou d'une autre lorsque les méthodes de supertrait deviendront appelables sur des objets de trait.

Cela est devenu plus compliqué avec DST car vous pouvez avoir des objets comme Fat<Trait> où Fat est une structure DST. Le code stub pour les objets trait est un peu plus cassé, mais je ne veux pas le corriger car il ne s'agit que d'un stub. J'y ai laissé un FIXME.

Triage bump : je ne sais pas quel en est le statut aujourd'hui.

doit encore faire

Nous pourrions effectuer les opérations suivantes :
(1) Créez une description de type pour chaque trait qui contient les méthodes qu'il définit. Puisqu'il n'y a pas encore de traits dans la norme DWARF, l'utilisation de DW_AT_interface serait la plus logique. Mais peut-être que l'utilisation de DW_AT_struct est plus compatible avec nos débogueurs orientés C.

(2) Décrivez les pointeurs de traits ( &Trait et al) comme des tuples de type (*(), *OpaqueVTable<Trait>) .

(3) Implémentez des commandes GDB/LLDB personnalisées en Python qui, étant donné un gros pointeur, utilisent la valeur du pointeur et les informations de type pour imprimer la vtable.

Ce n'est pas parfait mais cela pourrait être fait avec les moyens actuels disponibles. Les noms de symboles des fonctions pointées par la vtable doivent également indiquer le type d'exécution réel de l'objet trait.

Uniquement dans les builds avec des informations de débogage (c'est-à-dire pas les builds de version) et seulement d'une très petite quantité

Triage : reste à faire. cc @Manishearth @tromey P-low

C'est à la fois P-low et P-medium maintenant

Retrait du support P

Je me suis un peu penché là-dessus récemment. Ce que j'espère faire c'est :

• Émettez du DWARF décrivant chaque vtable émise. Cela décrirait le type de la table virtuelle (en tant que structure de pointeurs vers la fonction), l'emplacement de la table virtuelle et le type concret représenté par cette table virtuelle (peut-être que DW_AT_containing_type peut être réutilisé pour cela).
• Décrivez plus en détail l'intérieur d'un pointeur d'objet trait. Actuellement, je pense que cela doit être fait via un petit hack, car tandis que DWARF décrit un moyen de calculer le slot vtable d'une fonction donnée, il ne semble pas avoir de moyen d'indiquer "ce membre de l'objet est le vtable" .

Ensuite, un débogueur peut faire ce qui suit pour imprimer un pointeur d'objet trait : si le type d'une valeur a une vtable, récupérez la vtable de l'inférieur, recherchez l'adresse de la vtable dans le DWARF pour trouver le type de la vtable, puis utilisez le type concret pour décoder le pointeur de charge utile.

Je travaille là-dessus. J'ai un patch LLVM pour laisser rustc émettre une petite idée d'extension DWARF (le DW_AT_containing_type ); un patch rustc pour émettre les bases de la vtable (adresse et type de conteneur, ne pas émettre les méthodes), et la plupart d'un patch gdb pour tout lire et faire fonctionner print .

Premier succès aujourd'hui :

(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

Passionnant!

Le correctif LLVM est ici : http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20171016/495458.html

Déplacé au phabrificateur ; pourrait être plus simple à suivre là aussi : https://reviews.llvm.org/D39503

Le correctif gdb pour l'impression des objets trait est ici : https://sourceware.org/ml/gdb-patches/2017-11/msg00289.html

La partie 2 peut être faite en décrivant les champs de la vtable. Je n'ai pas encore regardé les morceaux de rouille pour voir à quel point c'est difficile. Les bits info vtbl dans gdb ne sont pas difficiles, la plupart du temps il suffit de virtualiser un peu plus la commande existante. Avec des noms de champs corrects, il semble que l'implémentation d'appels de méthode sur des objets trait devrait également être simple.

La version 2 du correctif gdb est ici : https://sourceware.org/ml/gdb-patches/2017-11/msg00369.html

Le correctif gdb est maintenant disponible, mais je pense que ce problème doit rester ouvert, car il reste encore l'autre tâche vtable à implémenter.

@tromey la "tâche vtable" nécessite-t-elle des modifications de gdb ou simplement des modifications de rustc ?

@tromey la "tâche vtable" nécessite-t-elle des modifications de gdb ou simplement des modifications de rustc ?

Idéalement, je pense qu'il faudrait les deux ; Cependant, faire juste les morceaux de rouille serait un bon début (et cela doit venir en premier de toute façon). La tâche ici est de faire en sorte que rustc émette une description complète de la vtable dans le DWARF -- donc, le type et le nom de chaque membre.