[LLVMdev] Debugging LLVM IR

[Duncan Sands]

Hi Dirkjan, the format string fmt_INT isn't null terminated.

Ciao, Duncan.

> I'm trying to write a compiler for a language that seems useful. I
> decided to target LLVM and write the compiler to just print out IR as
> text, instead of using the API's. This allows me to focus on the IR
> instead of having to learn the API as well, which kind of seems like
> an extra obstacle at this point. Anyway, writing out IR seems like a
> nice enough way to learn LLVM, except that there are some rough edges
> when dealing with IR that may contain stupid mistakes. For example,
> yesterday I filed PR 11880 [1], wherein I crash clang by throwing
> invalid IR at it. Consensus on IRC seems to be the clang should enable
> the LLVM verifier when taking IR as input, which seems useful.
>
> To circumvent the default of disabling the verifier when using clang
> to compile IR, I started trying to use lli, which does seem to run the
> verifier (i.e. it throws useful errors at me when I do something
> stupid). However, I've now run into a new problem with a small test
> program [2]: it does the right thing when run with lli, but shows
> spurious output (e.g. it repeats the first string printed right after
> printing the second string) when compiled with clang, then run.
> However, when I run lli with -use-mcjit, lli segfaults.
>
> Anyway, I've looked at the IR generated by clang for a roughly
> equivalent C program and have a hard time figuring out when I'm going
> wrong. Another problem here is that I'm not aware of any good ways to
> debug IR. I tried gdb a little bit, but it doesn't seem to understand
> IR. And I ran my program under valgrind, but nothing useful showed up
> there, either. I tried to figure out someways of printf'ing pointers
> and values straight from the IR, but that doesn't work. Perhaps it
> would be useful to add an instruction for that? It also seems like lli
> should be fertile ground for better debugging tools; I imagine it
> should technically not be too hard to print out a blow-by-blow of the
> evolution of my program's state...
>
> Anyway, if anyone has some hints to help me debug this stuff, that
> would be most welcome.
>
> Cheers,
>
> Dirkjan
>
> [1] http://llvm.org/bugs/show_bug.cgi?id=11880
> [2] http://paste.pocoo.org/show/542941/
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev