How to debug .ll file with segmentation fault?


I edited a working .ll file and llvm-as it to a .bc file. But it
causes segmentation fault. I don't know how to debug such errors.
Could anybody show me the best way to debug such errors? Thanks.

$ TRACE_OUTFILE=/tmp/trace.txt lli /tmp/y/bash_trcr.bc --norc
LLVMSymbolizer: error reading file: No such file or directory
#0 0x00007f162b1ee0ea llvm::sys::PrintStackTrace(llvm::raw_ostream&)
#1 0x00007f162b1ec366 llvm::sys::RunSignalHandlers()
#2 0x00007f162b1ec49b (/usr/lib/llvm-6.0/bin/../lib/
#3 0x00007f162a7c3890 __restore_rt
#4 0x00007f162a0923cc _IO_vfprintf
#5 0x00007f162a09be54 _IO_fprintf
#6 0x00007f1628ff648e
#7 0x00007f1628e37bc0
#8 0x00007f1628ff63a4
#9 0x00007f1628fc89e5
#10 0x00007f162c3cd79d llvm::MCJIT::runFunction(llvm::Function*,
#11 0x00007f162c3a67f7
std::vector<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >,
std::char_traits<char>, std::allocator<char> > > > const&, char const*
const*) (/usr/lib/llvm-6.0/bin/../lib/
#12 0x0000563cd2ca472b (lli+0x2772b)
#13 0x00007f162a058b97 __libc_start_main
#14 0x0000563cd2cad34a (lli+0x3034a)
Stack dump:
0. Program arguments: lli /tmp/y/bash_trcr.bc --norc
Segmentation fault

Hey Peng,

I’m really excited that you’re working with LLVM, but I don’t think this list is really the best place to get help with the basics of debugging. I’m afraid you’ll need to debug this (and learn how to debug this) kind of failure yourself. There are lots of documents and even some good books about this you can find with a quick search.

If you get to the point where there is clearly a bug in LLVM upstream, you can file it on our bug tracker of course.


Could you give specific pointers to the resources that are relevant to segmentation fault debugging? This kind of bug is the hardest to bebug because the error message has nothing to do with the actual bug.

Generic advices without consideration of specific properties of the problem will surely end up inefficient debugging.

What I added to the .ll file in this case are just function calls to write something to a file without touching any thing else in the original .ll. I can not envision how such changes can cause segmentation faults.

How can even be sure the bug is in the .ll code but not in lli?

Also, in this case, I don’t think running lli through lldb or gdb can be helpful, as it will show information of lli not the bitcode converted from the edited .ll file.

I suggest you try to AOT compile the IR and debug it in the same way as you would with native code.


Also, there is an entire document on debugging JIT-ed code that is likely useful:

Are you suggesting to compile it to executable? When I do this, there
is no segmentation fault. So this is due to a bug in lli?

$ llc -filetype=obj bash_trcr_B.bc
$ clang -Lxxx -lxxx /tmp/y/bash_trcr_B.o -o /tmp/y/bash_trcr_B.exe