Rust: Adicionar representação de depuração de objetos de característica

O que seria uma representação de depuração de um traço? Eu penso em um Trait como uma entidade puramente de tempo de compilação que é apagada no momento em que você chega ao tempo de execução.

@jdm Isso é especificamente para objetos @Trait (nesse caso, sim, concordo que gostaríamos de expor a vtable ao depurador?) Se sim, então

Sim, acho que definir o escopo para cobrir objetos de características (da variedade ~ e @) seria ótimo.

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

ou seja, ainda é válido, devidamente marcado e marcado, 19/06/2013.

Visita de triagem; adiando para @michaelwoerister.

Visita de triagem; adiando para @michaelwoerister.

Ainda é a JNI, mas deve ser abordado em algum momento deste mês.

Atualizar:

A partir do PR # 9168, há algum suporte básico para objetos de características. Um ponteiro de objeto de característica é descrito como uma estrutura com o tamanho correto (dois ponteiros) e o nome correto ({sigil} {mutabilidade} {nome da característica}) e é colocado no namespace correto. O interior deste "ponteiro gordo" ainda não foi descrito. O que falta é a descrição dos métodos do traço. Não sei o suficiente sobre como eles são realmente implementados para dizer muito sobre isso.

Não 1.0, mas alto

@michaelwoerister : A propósito, o novo layout da vtable é [drop_glue, method, method2, method3, ...] . Tenho certeza de que isso mudará no futuro de alguma forma, quando os métodos de supertrait se tornarem acessíveis em objetos de traço.

Isso ficou mais complicado com o DST, pois você pode ter objetos como Fat<Trait> onde Fat é uma estrutura DST. O código de stub para objetos de traço ficou um pouco mais quebrado, mas não quero consertá-lo, pois é apenas um esboço. Eu deixei um FIXME lá.

Saliência da triagem: não tenho certeza de qual é o status disso hoje.

ainda precisa fazer

Podemos fazer o seguinte:
(1) Crie descrições de tipo para cada característica que contenha os métodos que ela define. Como ainda não há traços no padrão DWARF, usar DW_AT_interface faria mais sentido. Mas talvez usar DW_AT_struct seja mais compatível com nossos depuradores orientados a C.

(2) Descreva os ponteiros de traço ( &Trait et al) como tuplas do tipo (*(), *OpaqueVTable<Trait>) .

(3) Implementar comandos GDB / LLDB personalizados em Python que, dado um ponteiro grande, usam o valor do ponteiro e as informações de tipo para imprimir a vtable.

Isso não é perfeito, mas poderia ser feito com os meios atuais disponíveis. Os nomes dos símbolos das funções apontadas pela vtable também devem indicar o tipo de tempo de execução real do objeto de característica.

Apenas em compilações com informações de depuração (ou seja, não compilações de lançamento) e apenas por uma quantidade muito pequena

Triagem: ainda precisa ser feito. cc @Manishearth @tromey P-low

Isso é P-low e P-medium agora

Removendo P-medium

Eu olhei para isso um pouco recentemente. O que espero fazer é:

• Emita algum DWARF descrevendo cada vtable que é emitida. Isso descreveria o tipo da vtable (como uma estrutura de ponteiros para função), a localização da vtable e o tipo concreto representado por essa vtable (talvez DW_AT_containing_type possa ser reaproveitado para isso).
• Descreva mais detalhadamente o interior de um ponteiro de objeto de característica. Atualmente acho que isso deve ser feito por meio de um pequeno hack, porque enquanto DWARF descreve uma maneira de calcular o slot vtable de uma determinada função, não parece haver uma maneira de indicar "este membro do objeto é a vtable" .

Em seguida, um depurador pode fazer o seguinte para imprimir um ponteiro de objeto de característica: se o tipo de um valor tem uma vtable, busque a vtable do inferior, procure o endereço da vtable no DWARF para encontrar o tipo vtable e, em seguida, use o tipo concreto para decodifique o ponteiro de carga útil.

Estou trabalhando nisso. Eu tenho um patch LLVM para permitir que rustc emita uma pequena extensão DWARF (a ideia DW_AT_containing_type ); um patch rustc para emitir o básico do vtable (endereço e tipo de conteúdo, não emite os métodos), e a maior parte do patch gdb para ler tudo e fazer print funcionar.

Primeiro sucesso hoje:

(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

Emocionante!

O patch LLVM está aqui: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20171016/495458.html

Movido para o phabricator; pode ser mais simples de seguir lá também: https://reviews.llvm.org/D39503

O patch gdb para imprimir objetos de características está aqui: https://sourceware.org/ml/gdb-patches/2017-11/msg00289.html

A Parte 2 pode ser feita descrevendo os campos da vtable. Eu não olhei os pedaços enferrujados para ver como isso é difícil ainda. Os info vtbl bits no gdb não são difíceis, principalmente virtualizando um pouco mais o comando existente. Com os nomes de campo corretos lá, parece que a implementação de chamadas de método em objetos de característica também deve ser direta.

A versão 2 do patch gdb está aqui: https://sourceware.org/ml/gdb-patches/2017-11/msg00369.html

O patch gdb está disponível agora, mas acho que esse problema deve ser deixado em aberto, pois ainda há a outra tarefa vtable para implementar.

@tromey a "tarefa vtable" requer mudanças gdb ou apenas mudanças rustc?

@tromey a "tarefa vtable" requer mudanças gdb ou apenas mudanças rustc?

Idealmente, acho que exigiria ambos; no entanto, apenas fazer os bits rustc seria um bom começo (e isso tem que vir primeiro de qualquer maneira). A tarefa aqui é fazer com que o rustc emita uma descrição completa da vtable no DWARF - portanto, o tipo e o nome de cada membro.