llvm dev - Jan 2012 - [LLVMdev] Debugging LLVM IR

Hi,

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/

<snip>
> 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.
>
Hi Dirkjan,

Unfortunately it won't be immediately helpful, but we're currently in
the middle of pushing a functional MC-JIT implementation for Linux
(and hopefully Windows as well) which will enable debugging out of the
box. Once the set of patches gets committed, it will be possible to
debug JITted code with GDB, if this code was compiled from C/C++ with
Clang. The debugging should work like any C code debugging.

However, as I said this is a work in progress and it may take some
time until its fully functional in LLVM trunk.

Eli

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