Rust: Tambahkan representasi debug dari objek sifat

Apa yang akan menjadi representasi debug dari suatu Sifat? Saya menganggap Trait sebagai entitas waktu kompilasi murni yang terhapus pada saat Anda mencapai runtime.

@jdm Apakah ini khusus untuk objek @Trait (dalam hal ini, ya, saya setuju kami ingin mengekspos vtable ke debugger?) Jika demikian, maka saya akan menghapus judul dan deskripsi bug.

Ya, saya pikir pelingkupan ini untuk menutupi objek sifat (dari ~ dan @ variasi) akan baik-baik saja.

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

yaitu ini masih valid, diberi tag dan tonggak dengan benar, 2013-06-19.

Kunjungan triase; tunduk pada @michaelwoerister.

Kunjungan triase; tunduk pada @michaelwoerister.

Ini masih NYI tetapi harus ditangani beberapa waktu bulan ini.

Memperbarui:

Pada PR #9168 ada beberapa dukungan dasar untuk objek sifat. Pointer objek sifat dideskripsikan sebagai struct dengan ukuran yang benar (dua pointer) dan nama yang benar ({sigil}{mutability}{trait name}) dan ditempatkan di namespace yang benar. Bagian dalam "penunjuk gemuk" ini belum dijelaskan lebih lanjut. Apa yang hilang adalah deskripsi metode sifat itu. Saya tidak cukup tahu tentang bagaimana mereka benar-benar diterapkan untuk mengatakan banyak tentang itu.

Bukan 1.0, tapi tinggi

@michaelwoerister : Omong-omong, tata letak vtable baru adalah [drop_glue, method, method2, method3, ...] . Saya yakin ini akan berubah di masa depan entah bagaimana ketika metode supertrait menjadi dapat dipanggil pada objek sifat.

Ini menjadi lebih rumit dengan DST karena Anda dapat memiliki objek seperti Fat<Trait> mana Fat adalah struct DST. Kode rintisan untuk objek sifat sedikit lebih rusak, tetapi saya tidak ingin memperbaikinya karena itu hanya sebuah rintisan. Saya meninggalkan FIXME di sana.

Benjolan triase: tidak yakin apa statusnya hari ini.

masih perlu dilakukan

Kita bisa melakukan hal berikut:
(1) Buat deskripsi tipe untuk setiap sifat yang berisi metode yang ditentukannya. Karena belum ada ciri-ciri dalam standar DWARF, menggunakan DW_AT_interface adalah yang paling masuk akal. Tapi mungkin menggunakan DW_AT_struct lebih kompatibel dengan debugger berorientasi C kami.

(2) Jelaskan pointer sifat ( &Trait et al) sebagai tupel tipe (*(), *OpaqueVTable<Trait>) .

(3) Terapkan perintah GDB/LLDB khusus dengan Python yang, dengan penunjuk gemuk, gunakan nilai penunjuk dan ketik informasi untuk mencetak tabel v.

Itu tidak sempurna tetapi bisa dilakukan dengan sarana yang tersedia saat ini. Nama simbol dari fungsi yang ditunjuk oleh vtable juga harus menunjukkan tipe runtime sebenarnya dari objek sifat.

Hanya dalam build dengan info debug (yaitu, bukan build rilis) dan hanya dengan jumlah yang cukup kecil

Triage: masih perlu dilakukan. cc @Manisharth @tromey P-low

Ini P-low dan P-medium sekarang

Menghapus P-medium

Saya melihat ini sedikit baru-baru ini. Yang saya harapkan adalah:

• Keluarkan beberapa DWARF yang menjelaskan setiap vtable yang dipancarkan. Ini akan menjelaskan tipe vtable (sebagai struct pointer-to-function), lokasi vtable, dan tipe konkret yang diwakili oleh vtable itu (mungkin DW_AT_containing_type dapat digunakan kembali untuk ini).
• Lebih lanjut menggambarkan interior pointer objek sifat. Saat ini saya pikir ini harus dilakukan melalui sedikit peretasan, karena sementara DWARF menjelaskan cara untuk menghitung slot vtable fungsi yang diberikan, sepertinya tidak ada cara untuk menunjukkan "anggota objek ini adalah vtable" .

Kemudian debugger dapat melakukan hal berikut untuk mencetak penunjuk objek sifat: jika tipe nilai memiliki vtable, ambil vtable dari inferior, cari alamat vtable di DWARF untuk menemukan tipe vtable, lalu gunakan tipe konkret untuk memecahkan kode penunjuk muatan.

Saya sedang mengerjakan ini. Saya memiliki tambalan LLVM untuk membiarkan rustc memancarkan ide ekstensi DWARF kecil ( DW_AT_containing_type ); tambalan rustc untuk memancarkan dasar-dasar vtable (alamat dan tipe yang berisi, bukan memancarkan metode), dan sebagian besar tambalan gdb untuk membaca semuanya dan membuat print berfungsi.

Sukses pertama hari ini:

(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

Menyenangkan!

Patch LLVM ada di sini: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20171016/495458.html

Pindah ke fabricator; mungkin lebih mudah untuk diikuti di sana juga: https://reviews.llvm.org/D39503

gdb patch untuk mencetak objek sifat ada di sini: https://sourceware.org/ml/gdb-patches/2017-11/msg00289.html

Bagian 2 dapat dilakukan dengan menggambarkan bidang dari vtable. Saya belum melihat bagian rustc untuk melihat betapa sulitnya ini. Bit info vtbl di gdb tidak sulit, kebanyakan hanya memvirtualisasikan perintah yang ada sedikit lebih banyak. Dengan nama bidang yang benar di sana, sepertinya menerapkan pemanggilan metode pada objek sifat juga harus mudah.

Versi 2 dari tambalan gdb ada di sini: https://sourceware.org/ml/gdb-patches/2017-11/msg00369.html

Tambalan gdb sudah masuk sekarang, tetapi saya pikir masalah ini harus dibiarkan terbuka, karena masih ada tugas vtable lain yang harus diterapkan.

@tromey apakah "tugas vtable" memerlukan perubahan gdb atau hanya perubahan rustc?

@tromey apakah "tugas vtable" memerlukan perubahan gdb atau hanya perubahan rustc?

Idealnya saya pikir itu akan membutuhkan keduanya; namun hanya melakukan bit rustc akan menjadi awal yang baik (dan bagaimanapun ini harus didahulukan). Tugas di sini adalah membuat rustc mengeluarkan deskripsi lengkap dari vtable di DWARF -- jadi, jenis dan nama setiap anggota.