Rust: Agregar representación de depuración de objetos de rasgo

¿Cuál sería una representación de depuración de un rasgo? Pienso en un Trait como una entidad puramente en tiempo de compilación que se borra cuando llegas al tiempo de ejecución.

@jdm ¿Es esto específicamente para objetos @Trait (en cuyo caso, sí, estoy de acuerdo en que aclararé el título y la descripción del error.

Sí, creo que establecer el alcance de esto para cubrir objetos de rasgo (de la variedad ~ y @) estaría bien.

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

es decir, esto sigue siendo válido, debidamente etiquetado y marcado, 2013-06-19.

Visita de triaje; difiriendo a @michaelwoerister.

Visita de triaje; difiriendo a @michaelwoerister.

Todavía es la JNI, pero debería abordarse en algún momento de este mes.

Actualizar:

A partir del PR # 9168, existe un soporte básico para objetos de rasgo. Un puntero de objeto de rasgo se describe como una estructura con el tamaño correcto (dos punteros) y el nombre correcto ({sigil} {mutability} {nombre de rasgo}) y se coloca en el espacio de nombres correcto. El interior de este "puntero gordo" aún no se describe más. Lo que falta es la descripción de los métodos del rasgo. No sé lo suficiente sobre cómo se implementan realmente para decir mucho sobre eso.

No 1.0, pero alto

@michaelwoerister : Por cierto, el nuevo diseño de vtable es [drop_glue, method, method2, method3, ...] . Estoy seguro de que esto cambiará en el futuro de alguna manera cuando los métodos de supertrait se vuelvan invocables en objetos de rasgo.

Esto se ha vuelto más complicado con DST ya que puede tener objetos como Fat<Trait> donde Fat es una estructura DST. El código de código auxiliar para los objetos de rasgo se ha roto un poco más, pero no quiero arreglarlo ya que es solo un código auxiliar. Ahí dejé un FIXME.

Triage bump: no estoy seguro de cuál es el estado de esto hoy.

todavía necesita hacer

Podríamos hacer lo siguiente:
(1) Cree descripciones de tipo para cada rasgo que contenga los métodos que define. Dado que todavía no hay rasgos en el estándar DWARF, usar DW_AT_interface tendría más sentido. Pero quizás usar DW_AT_struct sea ​​más compatible con nuestros depuradores orientados a C.

(2) Describa los indicadores de rasgos ( &Trait et al) como tuplas de tipo (*(), *OpaqueVTable<Trait>) .

(3) Implemente comandos GDB / LLDB personalizados en Python que, dado un puntero grueso, usan el valor del puntero y escribe información para imprimir el vtable.

Eso no es perfecto, pero podría hacerse con los medios disponibles actualmente. Los nombres de símbolo de las funciones señaladas por vtable también deben indicar el tipo de tiempo de ejecución real del objeto de rasgo.

Solo en compilaciones con información de depuración (es decir, no compilaciones de lanzamiento) y solo en una cantidad bastante pequeña

Triage: todavía hay que hacerlo. cc @Manishearth @tromey P-bajo

Esto es tanto P-low como P-medium ahora

Eliminación de medio P

Investigué esto un poco recientemente. Lo que espero hacer es:

• Emite algunos ENANOS que describen cada vtable que se emite. Esto describiría el tipo de vtable (como una estructura de punteros a función), la ubicación de vtable y el tipo concreto representado por ese vtable (tal vez DW_AT_containing_type pueda reutilizarse para esto).
• Describe con más detalle el interior de un puntero de objeto de rasgo. Actualmente, creo que esto debe hacerse mediante un truco, porque mientras DWARF describe una forma de calcular la ranura vtable de una función determinada, no parece tener una forma de indicar "este miembro del objeto es la vtable" .

Luego, un depurador puede hacer lo siguiente para imprimir un puntero de objeto de rasgo: si el tipo de un valor tiene una vtable, busque la vtable de la inferior, busque la dirección de la vtable en el DWARF para encontrar el tipo de vtable y luego use el tipo concreto para decodificar el puntero de carga útil.

Estoy trabajando en esto. Tengo un parche LLVM para permitir que rustc emita una pequeña extensión DWARF (la idea DW_AT_containing_type ); un parche rustc para emitir los conceptos básicos de la vtable (dirección y tipo de contenido, no emitir los métodos), y la mayoría de un parche gdb para leerlo todo y hacer que print funcione.

Primer éxito hoy:

(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

¡Excitante!

El parche LLVM está aquí: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20171016/495458.html

Movido a fabricador; también podría ser más sencillo seguir allí: https://reviews.llvm.org/D39503

El parche gdb para imprimir objetos de rasgo está aquí: https://sourceware.org/ml/gdb-patches/2017-11/msg00289.html

La parte 2 se puede realizar describiendo los campos de vtable. No he mirado las partes rustc para ver qué tan difícil es esto todavía. Los info vtbl bits en gdb no son difíciles, en su mayoría solo virtualizan un poco más el comando existente. Con los nombres de campo correctos allí, parece que la implementación de llamadas a métodos en objetos de características también debería ser sencilla.

La versión 2 del parche gdb está aquí: https://sourceware.org/ml/gdb-patches/2017-11/msg00369.html

El parche gdb ya está disponible, pero creo que este problema debería dejarse abierto, ya que todavía queda la otra tarea de vtable por implementar.

@tromey, ¿la "tarea vtable" requiere cambios de gdb o solo cambios de rustc?

@tromey, ¿la "tarea vtable" requiere cambios de gdb o solo cambios de rustc?

Idealmente, creo que requeriría ambos; sin embargo, solo hacer los bits rustc sería un buen comienzo (y esto tiene que ser lo primero de todos modos). La tarea aquí es hacer que rustc emita una descripción completa de la vtable en DWARF, es decir, el tipo y nombre de cada miembro.