Отладка LLVM IR

Question

Я построил интерфейс LLVM-targetting, который производит некоторый ИК-сигнал. Впоследствии и полностью ожидаемо, IR-выход в некоторых случаях некорректен (как и в, он выглядит корректно, но в результате программа вылетает при выполнении). Однако я не нашел много полезных инструментов для решения этой проблемы.

Я пробовал использовать lli, но вывод сообщения об ошибке впечатляюще бесполезен (когда вы предполагаете, что интерпретатор может дать очень точные сведения об ошибке).

Я искал преобразование кода IR в C, а затем отлаживал его с помощью Visual Studio, но, похоже, эта функция была удалена из LLVM.

Я также рассмотрел дело с GDB. Тем не менее, формат отладочной информации DWARF весьма специфичен для нескольких существующих языков, и, кроме того, источник, который я переводил с помощью моего интерфейса, верен, это произведенный IR, который является неправильным, поэтому символы отладки для исходного источника не будут 't быть слишком полезным - например, мне нужно будет увидеть значения пучка промежуточных значений регистра, которые не соответствуют какой-либо исходной переменной, или точка останова в сгенерированных компилятором функциях.

Какие инструменты и методы существуют для отладки выходного сигнала LLVM IR?

Answer 1

Я не уверен, что полностью понимаю вашу проблему. Вы говорите, что ваш компилятор (от языка X до LLVM IR) производит неправильный вывод (неправильный LLVM IR), и вы не знаете, как его отладить? Другими словами, есть две возможности:

1. IR, созданный вашим компилятором, неверен - вы можете указать некоторые инструкции и сказать - это не то, что я хотел создать.
2. IR кажется правильным, но не дает результатов, которые я ожидал от него.

Я предполагаю, что это (1) вы говорите (потому что это то, что говорил этот вопрос, прежде чем вы обновили его)

Это не будет LLVM конкретной проблемой, то. Предположим, вы пишете компилятор с языка X на собственный код. Созданный собственный код неверен - как вы отлаживаете проблему? Ну, вы отлаживаете свой компилятор, очевидно. Вы пытаетесь найти последнее место, где понимание компилятора ввода было правильным, или первое место, где оно стало неправильным. Как вы это делаете, это зависит от архитектуры вашего компилятора. Тем не менее, что-то, что очень помогает, имеет печатное представление других промежуточных уровней в вашем компиляторе.

Например, Clang (который производит LLVM IR от C, C++ и Objective C) может сбрасывать полный АСТ. Поэтому, глядя на AST для неправильного кода, вы можете сократить фрагмент кода, помогая определить, находится ли проблема в интерфейсе (источник C -> AST) или код gen (AST -> LLVM IR). Бэкэнд LLVM (компилирует LLVM IR на собственный код) также имеет несколько промежуточных уровней (в первую очередь SelectionDAG и MI), которые могут быть проверены для отладки. Это всего лишь примеры других существующих компиляторов YMMV с вашими.

Answer 2

Уилл Diez описал, как он реализован, что:
https://groups.google.com/d/msg/llvm-dev/O4Dj9FW1gtM/ovnm6dqoJJsJ

Привет всем,

Для моих собственных целей я написал пропуск, который делает именно то, что все, что вы описания: добавление отладочных метаданных к LLVM IR.

В проходе, он должен был решить проблему «Этот файл должен существовать на диске где-то так GDB может найти», который я решил мой выкачать его на/TMP/где-то. Не отличное решение (кто их удаляет?), Но работал достаточно хорошо.

Другой интересный вопрос заключается в том, чтобы сосуществовать с любой существующей отлаживать метаданных, которые могут быть полезны для одновременной отладки ИК преобразования рядный с источником C для приборов в стиле проходит как SafeCode Асан/Цан.

Быстрый пример:

(gdb) break main 
Breakpoint 1 at 0x4010b1: file 
/home/wdietz2/magic/test/unit/test_loop.c, line 9. 
(gdb) r 
Starting program: 
/home/wdietz2/llvm/32-obj-make/projects/magic/test/Output/test_loop 

Breakpoint 1, main (argc=<value optimized out>, argv=<value optimized 
out>) at /home/wdietz2/magic/test/unit/test_loop.c:9 
9   unsigned k = 0; 
Missing separate debuginfos, use: debuginfo-install 
glibc-2.12-1.80.el6_3.5.x86_64 libgcc-4.4.6-4.el6.x86_64 
libstdc++-4.4.6-4.el6.x86_64 
(gdb) n 
10  source(argc != 0, &k); 
(gdb) n 
14  %and.i.i.i.i104 = and i64 %4, 70368744177660 
(gdb) n 
15  %5 = load i8** @global, align 8 
(gdb) n 
18  store i32 16843009, i32* %6, align 1 
(gdb) n 
19  store i8 1, i8* getelementptr inbounds ([1 x i8]* @array, 
i64 0, i64 0), align 1 
(gdb) n 
20  call coldcc void @runtime_func() nounwind 
(gdb) n 
11  while(i-- > argc) 
(gdb) n 
23  %and.i.i.i.i85 = and i64 %7, 70368744177660 
(gdb) n 
14   while(j++ < i) k += j; 
(gdb) n 
11  while(i-- > argc) 
(gdb) n 
14   while(j++ < i) k += j; 
(gdb) n 
102  %77 = load i8** @global, align 8 
(gdb) n 
105  %79 = load i32* %78, align 4 
(gdb) n 
106  %cmp7.i.i.i = icmp ne i32 %79, 0 
(gdb) n 
108  call void @llvm.memset.p0i8.i64(i8* %add.ptr.i.i.i.i86, i8 
%conv8.i.i.i, i64 4, i32 1, i1 false) nounwind 
(gdb) n 
14   while(j++ < i) k += j; 
(gdb) n 
15   while(j-- > 0) k *= k + j; 
(gdb) n 
95  %69 = load i8** @global, align 8 
(gdb) n 
98  %71 = load i32* %70, align 4 
(gdb) 

Сам перевал довольно прост - сложная проблема, она решает это излучающие ИК на диск и рассуждения о том, что инструкция * на какой линии, которые на самом деле не должен» t быть проблемой, если сделано правильно в LLVM. При желании я могу сделать код доступным по запросу.

Короче говоря, мне показалось, что это хорошо работает для меня, и если это правильно сделано в , LLVM сам будет здорово!

К сожалению, похоже, что код не доступен.