Peng Yu via llvm-dev
2019-Jan-26 07:05 UTC
[llvm-dev] How to debug .ll file with segmentation fault?
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. On Fri, Jan 25, 2019 at 11:44 PM Chandler Carruth <chandlerc at gmail.com> wrote:> 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. > > -Chandler > > > On Fri, Jan 25, 2019 at 6:50 PM Peng Yu via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi, >> >> 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 >> __trace_init >> LLVMSymbolizer: error reading file: No such file or directory >> #0 0x00007f162b1ee0ea llvm::sys::PrintStackTrace(llvm::raw_ostream&) >> (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x81e0ea) >> #1 0x00007f162b1ec366 llvm::sys::RunSignalHandlers() >> (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x81c366) >> #2 0x00007f162b1ec49b >> (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x81c49b) >> #3 0x00007f162a7c3890 __restore_rt >> (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890) >> #4 0x00007f162a0923cc _IO_vfprintf >> /build/glibc-OTsEL5/glibc-2.27/stdio-common/vfprintf.c:1283:0 >> #5 0x00007f162a09be54 _IO_fprintf >> /build/glibc-OTsEL5/glibc-2.27/stdio-common/fprintf.c:36:0 >> #6 0x00007f1628ff648e >> #7 0x00007f1628e37bc0 >> #8 0x00007f1628ff63a4 >> #9 0x00007f1628fc89e5 >> #10 0x00007f162c3cd79d llvm::MCJIT::runFunction(llvm::Function*, >> llvm::ArrayRef<llvm::GenericValue>) >> (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x19fd79d) >> #11 0x00007f162c3a67f7 >> llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*, >> std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, >> std::allocator<char> >, >> std::allocator<std::__cxx11::basic_string<char, >> std::char_traits<char>, std::allocator<char> > > > const&, char const* >> const*) (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x19d67f7) >> #12 0x0000563cd2ca472b (lli+0x2772b) >> #13 0x00007f162a058b97 __libc_start_main >> /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:344:0 >> #14 0x0000563cd2cad34a (lli+0x3034a) >> Stack dump: >> 0. Program arguments: lli /tmp/y/bash_trcr.bc --norc >> Segmentation fault >> >> -- >> Regards, >> Peng >> > _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > --Regards, Peng -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190126/edb7ee4b/attachment.html>
mayuyu.io via llvm-dev
2019-Jan-26 07:19 UTC
[llvm-dev] How to debug .ll file with segmentation fault?
I suggest you try to AOT compile the IR and debug it in the same way as you would with native code. Zhang> 在 2019年1月26日，07:05，Peng Yu via llvm-dev <llvm-dev at lists.llvm.org> 写道： > > 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. > >> On Fri, Jan 25, 2019 at 11:44 PM Chandler Carruth <chandlerc at gmail.com> wrote: >> 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. >> >> -Chandler >> >> >>> On Fri, Jan 25, 2019 at 6:50 PM Peng Yu via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> >>> Hi, >>> >>> 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 >>> __trace_init >>> LLVMSymbolizer: error reading file: No such file or directory >>> #0 0x00007f162b1ee0ea llvm::sys::PrintStackTrace(llvm::raw_ostream&) >>> (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x81e0ea) >>> #1 0x00007f162b1ec366 llvm::sys::RunSignalHandlers() >>> (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x81c366) >>> #2 0x00007f162b1ec49b (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x81c49b) >>> #3 0x00007f162a7c3890 __restore_rt >>> (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890) >>> #4 0x00007f162a0923cc _IO_vfprintf >>> /build/glibc-OTsEL5/glibc-2.27/stdio-common/vfprintf.c:1283:0 >>> #5 0x00007f162a09be54 _IO_fprintf >>> /build/glibc-OTsEL5/glibc-2.27/stdio-common/fprintf.c:36:0 >>> #6 0x00007f1628ff648e >>> #7 0x00007f1628e37bc0 >>> #8 0x00007f1628ff63a4 >>> #9 0x00007f1628fc89e5 >>> #10 0x00007f162c3cd79d llvm::MCJIT::runFunction(llvm::Function*, >>> llvm::ArrayRef<llvm::GenericValue>) >>> (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x19fd79d) >>> #11 0x00007f162c3a67f7 >>> llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*, >>> std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, >>> std::allocator<char> >, >>> std::allocator<std::__cxx11::basic_string<char, >>> std::char_traits<char>, std::allocator<char> > > > const&, char const* >>> const*) (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x19d67f7) >>> #12 0x0000563cd2ca472b (lli+0x2772b) >>> #13 0x00007f162a058b97 __libc_start_main >>> /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:344:0 >>> #14 0x0000563cd2cad34a (lli+0x3034a) >>> Stack dump: >>> 0. Program arguments: lli /tmp/y/bash_trcr.bc --norc >>> Segmentation fault >>> >>> -- >>> Regards, >>> Peng >> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > -- > Regards, > Peng > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190126/58fcdd7d/attachment.html>
Chandler Carruth via llvm-dev
2019-Jan-26 07:23 UTC
[llvm-dev] How to debug .ll file with segmentation fault?
Also, there is an entire document on debugging JIT-ed code that is likely useful: https://llvm.org/docs/DebuggingJITedCode.html On Fri, Jan 25, 2019 at 11:19 PM mayuyu.io <admin at mayuyu.io> wrote:> I suggest you try to AOT compile the IR and debug it in the same way as > you would with native code. > > Zhang > > 在 2019年1月26日，07:05，Peng Yu via llvm-dev <llvm-dev at lists.llvm.org> 写道： > > 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. > > On Fri, Jan 25, 2019 at 11:44 PM Chandler Carruth <chandlerc at gmail.com> > wrote: > >> 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. >> >> -Chandler >> >> >> On Fri, Jan 25, 2019 at 6:50 PM Peng Yu via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Hi, >>> >>> 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 >>> __trace_init >>> LLVMSymbolizer: error reading file: No such file or directory >>> #0 0x00007f162b1ee0ea llvm::sys::PrintStackTrace(llvm::raw_ostream&) >>> (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x81e0ea) >>> #1 0x00007f162b1ec366 llvm::sys::RunSignalHandlers() >>> (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x81c366) >>> #2 0x00007f162b1ec49b >>> (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x81c49b) >>> #3 0x00007f162a7c3890 __restore_rt >>> (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890) >>> #4 0x00007f162a0923cc _IO_vfprintf >>> /build/glibc-OTsEL5/glibc-2.27/stdio-common/vfprintf.c:1283:0 >>> #5 0x00007f162a09be54 _IO_fprintf >>> /build/glibc-OTsEL5/glibc-2.27/stdio-common/fprintf.c:36:0 >>> #6 0x00007f1628ff648e >>> #7 0x00007f1628e37bc0 >>> #8 0x00007f1628ff63a4 >>> #9 0x00007f1628fc89e5 >>> #10 0x00007f162c3cd79d llvm::MCJIT::runFunction(llvm::Function*, >>> llvm::ArrayRef<llvm::GenericValue>) >>> (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x19fd79d) >>> #11 0x00007f162c3a67f7 >>> llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*, >>> std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, >>> std::allocator<char> >, >>> std::allocator<std::__cxx11::basic_string<char, >>> std::char_traits<char>, std::allocator<char> > > > const&, char const* >>> const*) (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x19d67f7) >>> #12 0x0000563cd2ca472b (lli+0x2772b) >>> #13 0x00007f162a058b97 __libc_start_main >>> /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:344:0 >>> #14 0x0000563cd2cad34a (lli+0x3034a) >>> Stack dump: >>> 0. Program arguments: lli /tmp/y/bash_trcr.bc --norc >>> Segmentation fault >>> >>> -- >>> Regards, >>> Peng >>> >> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> -- > Regards, > Peng > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190125/5ba1f58c/attachment.html>
Peng Yu via llvm-dev
2019-Jan-26 14:52 UTC
[llvm-dev] How to debug .ll file with segmentation fault?
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> I suggest you try to AOT compile the IR and debug it in the same way as you would with native code.-- Regards, Peng