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?
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.
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.
You can now build and debug the project using the Clang tools.
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).
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.
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. %0
, %1
but meaningful %names
) -- they appear as comments in llc
output. opt --dot-cfg 1.ll; dot cfg.funcname.dot -Tpng > 1.png
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With