Rust: Добавить отладочное представление трейт-объектов

Каким будет отладочное представление признака? Я думаю о Trait как о сущности времени компиляции, которая стирается к моменту, когда вы переходите во время выполнения.

@jdm Это специально для объектов @Trait (в этом случае, да, я согласен, что мы хотели бы открыть vtable для отладчика?) Если да, то я проясню заголовок и описание ошибки.

Да, я думаю, что можно было бы охватить это объектами-признаками (разнообразия ~ и @).

Согласно middle/trans/debuginfo.rs : cx.sess.span_note(span, "debuginfo for trait NYI");

т.е. это все еще актуально, правильно помечено и помечено, 2013-06-19.

Посещение сортировки; полагаясь на @michaelwoerister.

Посещение сортировки; полагаясь на @michaelwoerister.

Это все еще NYI, но ее нужно решить в этом месяце.

Обновлять:

Начиная с PR # 9168 существует некоторая базовая поддержка для признаков-объектов. Указатель на объект признака описывается как структура с правильным размером (два указателя) и правильным именем ({sigil} {изменчивость} {trait name}) и помещается в правильное пространство имен. Внутреннее устройство этого «толстого указателя» дальше не описывается. Чего не хватает, так это описания методов трейта. Я недостаточно знаю о том, как они реализуются на самом деле, чтобы много говорить об этом.

Не 1.0, но высокий

@michaelwoerister : Кстати, новый макет vtable - [drop_glue, method, method2, method3, ...] . Я уверен, что это как-то изменится в будущем, когда методы супертраитов станут вызываемыми для объектов-признаков.

С DST все стало сложнее, так как у вас могут быть такие объекты, как Fat<Trait> где Fat - это структура DST. Код-заглушка для трейт-объектов немного поврежден, но я не хочу его исправлять, поскольку это всего лишь заглушка. Я оставил там FIXME.

Шишка при сортировке: не знаю, в каком состоянии это сегодня.

все еще нужно делать

Мы могли сделать следующее:
(1) Создайте описания типов для каждой характеристики, которые содержат методы, которые она определяет. Поскольку в стандарте DWARF еще нет признаков, использование DW_AT_interface было бы наиболее разумным. Но, возможно, использование DW_AT_struct более совместимо с нашими C-ориентированными отладчиками.

(2) Опишите указатели на признаки ( &Trait и др.) Как кортежи типа (*(), *OpaqueVTable<Trait>) .

(3) Реализуйте пользовательские команды GDB / LLDB в Python, которые, учитывая толстый указатель, используют значение указателя и информацию о типе для печати vtable.

Это не идеально, но можно сделать с помощью имеющихся средств. Имена символов функций, на которые указывает vtable, также должны указывать на фактический тип времени выполнения объекта характеристики.

Только в сборках с отладочной информацией (т. Е. Не сборках выпуска) и только в очень небольшом количестве

Сортировка: еще нужно сделать. cc @Manishearth @tromey P-low

Это и P-low и P-medium сейчас

Удаление P-medium

Я недавно немного разобрался в этом. Я надеюсь сделать следующее:

• Создайте некоторый DWARF, описывающий каждую создаваемую виртуальную таблицу. Это будет описывать тип vtable (как структуру указателей на функцию), расположение vtable и конкретный тип, представленный этой vtable (возможно, DW_AT_containing_type может быть перепрофилирован для этого).
• Далее опишите внутреннюю часть указателя на объект признака. В настоящее время я думаю, что это нужно сделать с помощью небольшого взлома, потому что, хотя DWARF описывает способ вычисления слота vtable данной функции, похоже, нет способа указать, что «этот член объекта является vtable» .

Затем отладчик может сделать следующее, чтобы напечатать указатель объекта признака: если тип значения имеет vtable, извлечь vtable из подчиненного, найти адрес vtable в DWARF, чтобы найти тип vtable, а затем использовать конкретный тип для декодировать указатель полезной нагрузки.

Я над этим работаю. У меня есть патч LLVM, позволяющий rustc выдавать небольшое расширение DWARF (идея DW_AT_containing_type ); патч rustc для генерации основ vtable (адрес и содержащий тип, а не испускание методов) и большую часть патча gdb, чтобы прочитать все это и заставить print работать.

Первый успех сегодня:

(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

Захватывающий!

Патч LLVM находится здесь: http://lists.llvm.org/pipermail/llvm-commit/Week-of-Mon-20171016/495458.html

Перешел на фабрикатор; там тоже может быть проще: https://reviews.llvm.org/D39503

Патч gdb для печати трейт-объектов находится здесь: https://sourceware.org/ml/gdb-patches/2017-11/msg00289.html

Часть 2 можно выполнить, описав поля vtable. Я еще не смотрел на кусочки ржавчины, чтобы понять, насколько это сложно. Биты info vtbl в gdb несложны, в основном просто немного виртуализируют существующую команду. С правильными именами полей кажется, что реализация вызовов методов для объектов-признаков также должна быть простой.

Версия 2 патча gdb находится здесь: https://sourceware.org/ml/gdb-patches/2017-11/msg00369.html

Исправлен gdb, но я думаю, что эту проблему следует оставить открытой, поскольку есть еще одна задача vtable, которую нужно реализовать.

@tromey: "Задача vtable" требует изменений gdb или просто изменений rustc?

@tromey: "Задача vtable" требует изменений gdb или просто изменений rustc?

В идеале, я думаю, потребуется и то, и другое; тем не менее, простое выполнение битов rustc было бы хорошим началом (и в любом случае это должно быть первым). Задача здесь состоит в том, чтобы rustc выдал полное описание vtable в DWARF - то есть, тип и имя каждого члена.