Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Is there a debugger for LLVM IR?

Tags:

llvm

llvm-ir

I would like to step through some LLVM IR code I have generated. The code is syntactically and type valid as far as the llc and lli are concerned, but the results are not what I expected.

The chunks are large enough that I have been unsuccessful in simply reading out the bug, and I am having a hard time producing a smaller example with the same bug.

I figured that I could use something like a debugger, but for LLVM IR. In other words, I want to be able to step through the llvm code, examine the "infinite" registers (given the names in the LLVM IR file)and memory locations, set breakpoints, until I find where my code went wrong.

I looked into lli and lldb, but neither seems to be the tool I am looking for. lli will run my code but not let me go step by step. lldb seems to assume the code was generated by C frontends.

Am I wrong about lldb and lli? Does anyone know of a tool that does even 50% of what I want?

like image 862
orm Avatar asked Aug 13 '15 09:08

orm


People also ask

How do you read LLVM IR?

LLVM uses BasicBlock to represent groups of instructions, and a basic block has an exit point and a list of instructions. My guess would be that the compiler has decided to use the return as the exit from the basic block and has opted to put in at least one instruction into the block.

Is LLVM IR assembly?

LLVM IR is a low-level intermediate representation used by the LLVM compiler framework. You can think of LLVM IR as a platform-independent assembly language with an infinite number of function local registers.

Is Clang a debugger?

You can now build and debug the project using the Clang tools.

What is LLDB stand for?

LLDB (low-level debugger) is part of LLVM LLDB is Apple's “from the ground up” replacement for GDB. The LLDB debugger is analogous to GDB: (The GNU Project Debugger).


1 Answers

I am not aware of such a thing (I suspect it does not exist). Though I will gladly share my points on llvm produced code debugging.

  1. Debug the generated code itself (step though it in gdb).
  2. Make use of the debugtrap intrinsic (which simply generates int3 or whatever equivalent on your architecture). You can make assertions with this thing and see which of them fails.
  3. Give your instructions names (so they are not %0, %1 but meaningful %names) -- they appear as comments in llc output.
  4. Build a CFG (control flow graph) for your function: opt --dot-cfg 1.ll; dot cfg.funcname.dot -Tpng > 1.png
  5. Don't forget to disable llvm optimizations (you can have backend -O3 optimization level, but IR transformation passes can make it harder to debug).

So the workflow I am suggesting is as follows. Build a CFG (4.) and assembly (via llc). Break to the generated code in gdb and step through it (or let it trap on one of your asserions). Correlate the point at which you stopped in gdb to llc output, read the comment, corellate to the CFG. Grok.

You can also build CFG representation out of the generated code. Of the tools I know IDA Pro (a very expensive way to build CFGs) and Saga offer such functionality.

P.S.: This was initially a comment, but it grew too long.

like image 122
Vladislav Ivanishin Avatar answered Oct 06 '22 23:10

Vladislav Ivanishin