We're using the LLVM 3.3 AArch64 disassembler in the following way. We have built LLVM 3.3 on Linux as a shared library; and have a main program that dynamically loads shared objects (.so libraries). The program is a simulator (though that shouldn't be relevant to this question), and the shared objects it loads are electronic components that participate in the simulation. If the electronic component happens to be an ARM processor, it will make reference to the LLVM 3.3 shared library - specifically the AArch64 disassembler. The problem is this. For some simulations, the LLVM shared library seems to take a segfault on exit. It runs correctly, but when the simulator finishes, it crashes on exit. I've traced this back to the LLVM library by running the following experiment - run a known "good" simulator build without any references to LLVM, and observed that it runs correctly. Now rebuild the known "good" shared objects (the electronic components in the simulation), and link to the LLVM shared library. Still no references in the code to LLVM, just linking to the LLVM shared library. This causes the LLVM shared library to be loaded when the simulation is run; and this causes the failure on exit. Does anybody have any ideas as to why this might be happening? Rick Sullivan Carbon Design Systems 125 Nagog Park Rd, Acton, MA 01720 O: +1 (978) 264-7370 | M: +1 (508) 479-3845 [cid:image001.jpg at 01CE7B16.AF255740]<http://www.carbonipexchange.com/>[cid:image002.jpg at 01CE7B16.AF255740]<http://www.carbonipexchange.com/>[cid:image003.jpg at 01CE7B16.AF255740]<http://www.carbondesignsystems.com/CMS/UI/Modules/BizBlogger/rss.aspx?tabid=588537&moduleid=1218634&maxcount=25&t=f1e8c820-d905-4d3b-884d-9baca8a2f8d0>[cid:image004.jpg at 01CE7B16.AF255740]<http://www.twitter.com/CarbonDesignSys>[cid:image005.jpg at 01CE7B16.AF255740]<http://www.linkedin.com/company/20768>[cid:image006.jpg at 01CE7B16.AF255740]<http://www.facebook.com/pages/Carbon-Design-Systems/121129244611961?sk=wall> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130708/4474524d/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 768 bytes Desc: image001.jpg URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130708/4474524d/attachment.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 976 bytes Desc: image002.jpg URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130708/4474524d/attachment-0001.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 731 bytes Desc: image003.jpg URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130708/4474524d/attachment-0002.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 709 bytes Desc: image004.jpg URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130708/4474524d/attachment-0003.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.jpg Type: image/jpeg Size: 757 bytes Desc: image005.jpg URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130708/4474524d/attachment-0004.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.jpg Type: image/jpeg Size: 728 bytes Desc: image006.jpg URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130708/4474524d/attachment-0005.jpg>
Rick Sullivan <ricks at carbondesignsystems.com> writes: [snip]> The problem is this. For some simulations, the LLVM shared library > seems to take a segfault on exit. It runs correctly, but when the > simulator finishes, it crashes on exit.[snip]> > Does anybody have any ideas as to why this might be happening?Can you run the application under gdb and obtain a backtrace? Using a LLVM Debug build may (or may not) help on this endeavour.
Unfortunately, I haven't been able to get the failure to occur in gdb. Our crash handler generates a back trace, but it doesn't supply much information: 0: /o/release/SoCD/mainline/PRODUCT/Linux/bin/Linux//release/socdesigner(_ZN12CrashHandler12GetBacktraceEPc+0x2b) [0x8209adb] CrashHandler::GetBacktrace(char*) 1: /o/release/SoCD/mainline/PRODUCT/Linux/bin/Linux//release/socdesigner(_ZN12CrashHandler14GenerateReportEv+0x204) [0x820a434] CrashHandler::GenerateReport() 2: /o/release/SoCD/mainline/PRODUCT/Linux/bin/Linux//release/socdesigner(_ZN12CrashHandler21DoAllReportGenerationEv+0x1c) [0x820a51c] CrashHandler::DoAllReportGeneration() 3: /o/release/SoCD/mainline/PRODUCT/Linux/bin/Linux//release/socdesigner(_ZN12CrashHandler9GotSignalEv+0x6a6) [0x820ac86] CrashHandler::GotSignal() 4: /o/release/SoCD/mainline/PRODUCT/Linux/bin/Linux//release/socdesigner(_Z14CSignalHandleri+0x6c) [0x820b05c] CSignalHandler(int) 5: /lib/tls/libc.so.6 [0xc249b8] I've also tried running simulations without using libLLVM-3.3.so, but instead statically linking the required LLVM .a libraries into the component shared objects. This is not an idea solution, because it effectively bundles LLVM into each component, more than doubling the size of each component on disk. However, this also produces a crash with a more meaningful stack trace. Whether this is related to the failures I'm seeing with the LLVM shared object - I don't know. Here is the valgrind report: ==15093== Jump to the invalid address stated on the next line ==15093== at 0x0: ??? ==15093== by 0x285C2321: llvm::cl::parser<(anonymous namespace)::DefaultOnOff>::~parser() (CommandLine.h:629) ==15093== by 0x285C23D9: llvm::cl::opt<(anonymous namespace)::DefaultOnOff, false, llvm::cl::parser<(anonymous namespace)::DefaultOnOff>::~opt() (CommandLine.h:1 ==15093== by 0x285A3BD1: __tcf_5 (DwarfDebug.cpp:85) ==15093== by 0x441867: __cxa_finalize (in /lib/tls/libc-2.3.4.so) ==15093== by 0x282212F2: (within libCORTEXA9MP.mx_DBG.so) ==15093== by 0x28EEBB05: (within libCORTEXA9MP.mx_DBG.so) ==15093== by 0x518C41: _dl_close (in /lib/tls/libc-2.3.4.so) ==15093== by 0x56DD59: dlclose_doit (in /lib/libdl-2.3.4.so) ==15093== by 0x40966D: _dl_catch_error (in /lib/ld-2.3.4.so) ==15093== by 0x56E2BA: _dlerror_run (in /lib/libdl-2.3.4.so) ==15093== by 0x56DD89: dlclose (in /lib/libdl-2.3.4.so) -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Óscar Fuentes Sent: Monday, July 08, 2013 10:12 AM To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Problem Using libLLVM-3.3.so Rick Sullivan <ricks at carbondesignsystems.com> writes: [snip]> The problem is this. For some simulations, the LLVM shared library > seems to take a segfault on exit. It runs correctly, but when the > simulator finishes, it crashes on exit.[snip]> > Does anybody have any ideas as to why this might be happening?Can you run the application under gdb and obtain a backtrace? Using a LLVM Debug build may (or may not) help on this endeavour. _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev