<div dir="ltr"><div dir="ltr">Hi Dave<div><br></div><div>What sort of bitcode analysis are you doing? (does this relate to the dwarfdump crash - or is this a separate/unrelated issue?) </div><div>====================================================</div><div> In my llvm pass, I need to extract the intra-procedure cfg and print the source level debugging information for every IR. Then I can combine this information with the dwarf debugging information to get the binary level control flow graph. That is the reason why I need to do bitcode analysis. According to my experience, when I use the tool opt to load the llvm pass to analysis the bitcode, it took me rather a long time for large programs. To conclude, this doesn't related to dwarfdump crash, but if I use another version of llvm to compile the source code, I have to repeat this operation on all the target binaries to keep the consistent of the experiments.<br></div><div><br></div><div>If you've got an official LLVM release, that should be fine - if you've built LLVM yourself, the default is a Debug build (unoptimized, with assertions enabled) which will be quite slow. You probably want to build a Release build, or Release with Assertions. </div><div>==========================================</div><div>I build the LLVM by myself. I strictly follow the documentation here <a href="https://llvm.org/docs/GettingStarted.html">https://llvm.org/docs/GettingStarted.html</a><br></div><div>I would like to clarify my worries. For example, I have the source code, I use llvm-7 and llvm-8 to compile it with the same compiling commands. Then I get two binaries.  Any differences on these two binaries? Especially on the control flow graph. Many Thanks</div><div>I think this bug has been fixed in the newest version of llvm, right? I am afraid that if I use the llvm-8 to compile it and the dwarfdump crash will occur again.  <br></div><div><br></div><div>Ah, no worries. Reducing the test case may not require that much familiarity with the source code - fairly mechanically just removing bits of code, compiling it, then running dwarfdump to see if it crashes. Any change you make that still succeeds at compiling and crashes dwarfdump is good, keep going, keep removing bits of code/simplifying things (notice that the program doesn't need to /run/ (either at all, or correctly) since you're only testing if dwarfdump crashes). </div><div>================================</div><div>Got it. However, even if I could reduce the test case, I still cannot change it in my experiments since it is the standard benchmark. But it would be good for you guys to locate the original problem. I would be happy to do it after my deadline. </div><div><br></div><div>Many Thanks</div><div>Regards</div><div>Muhui </div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> 于2018年11月4日周日 上午4:28写道：<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sat, Nov 3, 2018 at 1:19 PM Muhui Jiang <<a href="mailto:jiangmuhui@gmail.com" target="_blank">jiangmuhui@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Dave</div><div dir="ltr"><div><br></div><div>Sorry, I meant the hardware you're using to compile LLVM - you mentioned it took you a long time to rebuild it so it would be hard for you to write/experiment on tests. </div></div><div dir="ltr"><div>=============================</div><div>Compiling LLVM doesn't take me too much time(less than 2 hours). The hardware is good enough and I am using interl E5 CPU.  </div></div></blockquote><div><br>Ah, OK<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>What I mean is that it took me a long time to analysis the bitcode.</div></div></blockquote><div><br>What sort of bitcode analysis are you doing? (does this relate to the dwarfdump crash - or is this a separate/unrelated issue?)<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div> If I recompile the binary, I need to re-analysis the bitcode. To make everything consistent, I need to re-compile and re-analysis the whole SPEC CPU.  Are there any differences on the binaries if I use different kinds of version LLVM?</div></div></blockquote><div><br>If you've got an official LLVM release, that should be fine - if you've built LLVM yourself, the default is a Debug build (unoptimized, with assertions enabled) which will be quite slow. You probably want to build a Release build, or Release with Assertions.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div> If not, I may try to download and compile the newest version of llvm and compile the specific binaries.<br></div></div><div dir="ltr"><div><br></div><div>Could you try reducing this test further? Taking the code/compile commands and try to reduce the remove anything in the source code that isn't needed to cause llvm-dwarfdump to crash?  <br></div></div><div dir="ltr"><div>=============================</div><div>I may not be able to reduce it. CPU SPEC is the standard benchmark and I am not very familiar to the source code. The target binary is also rather large. Sorry for that.</div></div></blockquote><div><br>Ah, no worries. Reducing the test case may not require that much familiarity with the source code - fairly mechanically just removing bits of code, compiling it, then running dwarfdump to see if it crashes. Any change you make that still succeeds at compiling and crashes dwarfdump is good, keep going, keep removing bits of code/simplifying things (notice that the program doesn't need to /run/ (either at all, or correctly) since you're only testing if dwarfdump crashes).<br><br>No worries though,<br>- Dave<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Regards</div><div>Muhui</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> 于2018年11月4日周日 上午4:02写道：<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sat, Nov 3, 2018 at 12:37 PM Muhui Jiang <<a href="mailto:jiangmuhui@gmail.com" target="_blank">jiangmuhui@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Dave<div><br></div><div>I am not going to access any hardware. </div></div></blockquote><div><br>Sorry, I meant the hardware you're using to compile LLVM - you mentioned it took you a long time to rebuild it so it would be hard for you to write/experiment on tests.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I am using clang to analysis the ARM binaries. The binary is 483.xalancbmk in CPU SPEC2006. When I use the optimization O0, no crash will occur. The crash occurs when I set optimization level as O1,O2,O3 and Os. </div></div></blockquote><div><br></div><div>Could you try reducing this test further? Taking the code/compile commands and try to reduce the remove anything in the source code that isn't needed to cause llvm-dwarfdump to crash?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>If I have to recompile and rerun the tests. What version of llvm is suggested. It would be better if anyone could provide the patch on this bug. </div><div><br></div><div>Regards</div><div>Muhui</div></div><br><div class="gmail_quote"><div dir="ltr">David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> 于2018年11月4日周日 上午2:58写道：<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sat, Nov 3, 2018 at 6:51 AM Muhui Jiang via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi <div><br></div><div>I come across the following exception when I use the llvm-dwarfdump -debug-info target_binary: </div><div><br></div><div>llvm-dwarfdump: /home/linux/llvm-7/llvm/lib/MC/MCRegisterInfo.cpp:87: int llvm::MCRegisterInfo::getLLVMRegNum(unsigned int, bool) const: Assertion `I != M+Size && I->FromReg == RegNum && "Invalid RegNum"' failed.</div><div>Stack dump:</div><div>0.      Program arguments: /home/linux/llvm-7/llvm/build/bin/llvm-dwarfdump -debug-info C++/483.xalancbmk.O1</div><div>#0 0x000000000093ab37 llvm::sys::PrintStackTrace(llvm::raw_ostream&) /home/linux/llvm-7/llvm/lib/Support/Unix/Signals.inc:490:0</div><div>#1 0x000000000093abca PrintStackTraceSignalHandler(void*) /home/linux/llvm-7/llvm/lib/Support/Unix/Signals.inc:554:0</div><div>#2 0x00000000009388d8 llvm::sys::RunSignalHandlers() /home/linux/llvm-7/llvm/lib/Support/Signals.cpp:67:0</div><div>#3 0x000000000093a531 SignalHandler(int) /home/linux/llvm-7/llvm/lib/Support/Unix/Signals.inc:353:0</div><div>#4 0x00007f39f47d7390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390)</div><div>#5 0x00007f39f374d428 gsignal /build/glibc-Cl5G7W/glibc-2.23/signal/../sysdeps/unix/sysv/linux/raise.c:54:0</div><div>#6 0x00007f39f374f02a abort /build/glibc-Cl5G7W/glibc-2.23/stdlib/abort.c:91:0</div><div>#7 0x00007f39f3745bd7 __assert_fail_base /build/glibc-Cl5G7W/glibc-2.23/assert/assert.c:92:0</div><div>#8 0x00007f39f3745c82 (/lib/x86_64-linux-gnu/libc.so.6+0x2dc82)</div><div>#9 0x00000000006e6ba1 llvm::MCRegisterInfo::getLLVMRegNum(unsigned int, bool) const /home/linux/llvm-7/llvm/lib/MC/MCRegisterInfo.cpp:88:0</div><div>#10 0x00000000004bd03e llvm::prettyPrintRegisterOp(llvm::raw_ostream&, unsigned char, unsigned long*, llvm::MCRegisterInfo const*, bool) /home/linux/llvm-7/llvm/lib/DebugInfo/DWARF/DWARFExpression.cpp:206:0</div><div>#11 0x00000000004bd226 llvm::DWARFExpression::Operation::print(llvm::raw_ostream&, llvm::DWARFExpression const*, llvm::MCRegisterInfo const*, bool) /home/linux/llvm-7/llvm/lib/DebugInfo/DWARF/DWARFExpression.cpp:237:0</div><div>#12 0x00000000004bd466 llvm::DWARFExpression::print(llvm::raw_ostream&, llvm::MCRegisterInfo const*, bool) const /home/linux/llvm-7/llvm/lib/DebugInfo/DWARF/DWARFExpression.cpp:264:0</div><div>#13 0x00000000004a8c68 dumpExpression(llvm::raw_ostream&, llvm::ArrayRef<char>, bool, unsigned int, llvm::MCRegisterInfo const*) /home/linux/llvm-7/llvm/lib/DebugInfo/DWARF/DWARFDebugLoc.cpp:38:0</div><div>#14 0x00000000004a8ea5 llvm::DWARFDebugLoc::LocationList::dump(llvm::raw_ostream&, bool, unsigned int, llvm::MCRegisterInfo const*, unsigned long, unsigned int) const /home/linux/llvm-7/llvm/lib/DebugInfo/DWARF/DWARFDebugLoc.cpp:45:0</div><div>#15 0x00000000004b331d dumpLocation(llvm::raw_ostream&, llvm::DWARFFormValue&, llvm::DWARFUnit*, unsigned int, llvm::DIDumpOptions) /home/linux/llvm-7/llvm/lib/DebugInfo/DWARF/DWARFDie.cpp:115:0</div><div>#16 0x00000000004b4034 dumpAttribute(llvm::raw_ostream&, llvm::DWARFDie const&, unsigned int*, llvm::dwarf::Attribute, llvm::dwarf::Form, unsigned int, llvm::DIDumpOptions) /home/linux/llvm-7/llvm/lib/DebugInfo/DWARF/DWARFDie.cpp:243:0</div><div>#17 0x00000000004b5cd2 llvm::DWARFDie::dump(llvm::raw_ostream&, unsigned int, llvm::DIDumpOptions) const /home/linux/llvm-7/llvm/lib/DebugInfo/DWARF/DWARFDie.cpp:521:0</div><div>#18 0x00000000004b5db4 llvm::DWARFDie::dump(llvm::raw_ostream&, unsigned int, llvm::DIDumpOptions) const /home/linux/llvm-7/llvm/lib/DebugInfo/DWARF/DWARFDie.cpp:530:0</div><div>#19 0x00000000004b5db4 llvm::DWARFDie::dump(llvm::raw_ostream&, unsigned int, llvm::DIDumpOptions) const /home/linux/llvm-7/llvm/lib/DebugInfo/DWARF/DWARFDie.cpp:530:0</div><div>#20 0x00000000004b5db4 llvm::DWARFDie::dump(llvm::raw_ostream&, unsigned int, llvm::DIDumpOptions) const /home/linux/llvm-7/llvm/lib/DebugInfo/DWARF/DWARFDie.cpp:530:0</div><div>#21 0x0000000000445cdd llvm::DWARFCompileUnit::dump(llvm::raw_ostream&, llvm::DIDumpOptions) /home/linux/llvm-7/llvm/lib/DebugInfo/DWARF/DWARFCompileUnit.cpp:31:0</div><div>#22 0x00000000004482ad llvm::DWARFContext::dump(llvm::raw_ostream&, llvm::DIDumpOptions, std::array<llvm::Optional<unsigned long>, 27ul>)::'lambda0'(bool, char const*, llvm::DWARFSection, llvm::iterator_range<std::unique_ptr<llvm::DWARFCompileUnit, std::default_delete<llvm::DWARFCompileUnit> >*>)::operator()(bool, char const*, llvm::DWARFSection, llvm::iterator_range<std::unique_ptr<llvm::DWARFCompileUnit, std::default_delete<llvm::DWARFCompileUnit> >*>) const /home/linux/llvm-7/llvm/lib/DebugInfo/DWARF/DWARFContext.cpp:351:0</div><div>#23 0x0000000000448e28 llvm::DWARFContext::dump(llvm::raw_ostream&, llvm::DIDumpOptions, std::array<llvm::Optional<unsigned long>, 27ul>) /home/linux/llvm-7/llvm/lib/DebugInfo/DWARF/DWARFContext.cpp:355:0</div><div>#24 0x0000000000414af6 dumpObjectFile(llvm::object::ObjectFile&, llvm::DWARFContext&, llvm::Twine, llvm::raw_ostream&) /home/linux/llvm-7/llvm/tools/llvm-dwarfdump/llvm-dwarfdump.cpp:424:0</div><div>#25 0x0000000000425d9a std::_Function_handler<bool (llvm::object::ObjectFile&, llvm::DWARFContext&, llvm::Twine, llvm::raw_ostream&), bool (*)(llvm::object::ObjectFile&, llvm::DWARFContext&, llvm::Twine, llvm::raw_ostream&)>::_M_invoke(std::_Any_data const&, llvm::object::ObjectFile&, llvm::DWARFContext&, llvm::Twine&&, llvm::raw_ostream&) /usr/include/c++/5/functional:1857:0</div><div>#26 0x0000000000420f69 std::function<bool (llvm::object::ObjectFile&, llvm::DWARFContext&, llvm::Twine, llvm::raw_ostream&)>::operator()(llvm::object::ObjectFile&, llvm::DWARFContext&, llvm::Twine, llvm::raw_ostream&) const /usr/include/c++/5/functional:2268:0</div><div>#27 0x0000000000415377 handleBuffer(llvm::StringRef, llvm::MemoryBufferRef, std::function<bool (llvm::object::ObjectFile&, llvm::DWARFContext&, llvm::Twine, llvm::raw_ostream&)>, llvm::raw_ostream&) /home/linux/llvm-7/llvm/tools/llvm-dwarfdump/llvm-dwarfdump.cpp:472:0</div><div>#28 0x0000000000415ae2 handleFile(llvm::StringRef, std::function<bool (llvm::object::ObjectFile&, llvm::DWARFContext&, llvm::Twine, llvm::raw_ostream&)>, llvm::raw_ostream&) /home/linux/llvm-7/llvm/tools/llvm-dwarfdump/llvm-dwarfdump.cpp:506:0</div><div>#29 0x00000000004170a4 main /home/linux/llvm-7/llvm/tools/llvm-dwarfdump/llvm-dwarfdump.cpp:623:0</div><div>#30 0x00007f39f3738830 __libc_start_main /build/glibc-Cl5G7W/glibc-2.23/csu/../csu/libc-start.c:325:0</div><div>#31 0x00000000004092e9 _start (/home/linux/llvm-7/llvm/build/bin/llvm-dwarfdump+0x4092e9)</div><div>Aborted (core dumped)</div><div> <br></div><div><br></div><div><div>After the google search. It seems that it should be an bug here <a href="https://www.mail-archive.com/llvm-bugs@lists.llvm.org/msg21648.html" target="_blank">https://www.mail-archive.com/llvm-bugs@lists.llvm.org/msg21648.html</a></div><div><br></div><div>I am using llvm 7.0 and cross compiled the binary with linaro arm toolchain(7.3.1). It takes me quiet a long time to compile and analysis the bitcode. Are there any solutions on fixing this without re-compiling the binary. Many Thanks</div></div></div></div></blockquote><div><br>Not much you can do to fix the bug if you can't readily recompile and rerun the tests - what sort of hardware do you have access to? (you might be able to reproduce this without ARM if your ARM machine has few cores/not much RAM but you have something else (X86 desktop machine) with more of both)<br><br>If you can't do that but would like to help move the bug forward anyway, a useful thing to do might be to try to find a reduced/small test case that demonstrates the issue to make it easier for someone else to investigate and fix the issue.<br><br>- Dave<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><div><br></div><div>Regards</div></div><div>Muhui</div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>
</blockquote></div></blockquote></div></div>
</blockquote></div></blockquote></div></div>
</blockquote></div>