[llvm-dev] llvm bug 36466 fix

Sat Nov 3 13:01:59 PDT 2018

On Sat, Nov 3, 2018 at 12:37 PM Muhui Jiang <jiangmuhui at gmail.com> wrote:

> Hi Dave
>
> I am not going to access any hardware.
>

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.

> 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.
>

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?

>
> 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.
>
> Regards
> Muhui
>
> David Blaikie <dblaikie at gmail.com> 于2018年11月4日周日 上午2:58写道：
>
>>
>>
>> On Sat, Nov 3, 2018 at 6:51 AM Muhui Jiang via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Hi
>>>
>>> I come across the following exception when I use the llvm-dwarfdump
>>> -debug-info target_binary:
>>>
>>> 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.
>>> Stack dump:
>>> 0.      Program arguments:
>>> /home/linux/llvm-7/llvm/build/bin/llvm-dwarfdump -debug-info
>>> C++/483.xalancbmk.O1
>>> #0 0x000000000093ab37 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
>>> /home/linux/llvm-7/llvm/lib/Support/Unix/Signals.inc:490:0
>>> #1 0x000000000093abca PrintStackTraceSignalHandler(void*)
>>> /home/linux/llvm-7/llvm/lib/Support/Unix/Signals.inc:554:0
>>> #2 0x00000000009388d8 llvm::sys::RunSignalHandlers()
>>> /home/linux/llvm-7/llvm/lib/Support/Signals.cpp:67:0
>>> #3 0x000000000093a531 SignalHandler(int)
>>> /home/linux/llvm-7/llvm/lib/Support/Unix/Signals.inc:353:0
>>> #4 0x00007f39f47d7390 __restore_rt
>>> (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390)
>>> #5 0x00007f39f374d428 gsignal
>>> /build/glibc-Cl5G7W/glibc-2.23/signal/../sysdeps/unix/sysv/linux/raise.c:54:0
>>> #6 0x00007f39f374f02a abort
>>> /build/glibc-Cl5G7W/glibc-2.23/stdlib/abort.c:91:0
>>> #7 0x00007f39f3745bd7 __assert_fail_base
>>> /build/glibc-Cl5G7W/glibc-2.23/assert/assert.c:92:0
>>> #8 0x00007f39f3745c82 (/lib/x86_64-linux-gnu/libc.so.6+0x2dc82)
>>> #9 0x00000000006e6ba1 llvm::MCRegisterInfo::getLLVMRegNum(unsigned int,
>>> bool) const /home/linux/llvm-7/llvm/lib/MC/MCRegisterInfo.cpp:88:0
>>> #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
>>> #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
>>> #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
>>> #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
>>> #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
>>> #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
>>> #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
>>> #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
>>> #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
>>> #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
>>> #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
>>> #21 0x0000000000445cdd llvm::DWARFCompileUnit::dump(llvm::raw_ostream&,
>>> llvm::DIDumpOptions)
>>> /home/linux/llvm-7/llvm/lib/DebugInfo/DWARF/DWARFCompileUnit.cpp:31:0
>>> #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
>>> #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
>>> #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
>>> #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
>>> #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
>>> #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
>>> #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
>>> #29 0x00000000004170a4 main
>>> /home/linux/llvm-7/llvm/tools/llvm-dwarfdump/llvm-dwarfdump.cpp:623:0
>>> #30 0x00007f39f3738830 __libc_start_main
>>> /build/glibc-Cl5G7W/glibc-2.23/csu/../csu/libc-start.c:325:0
>>> #31 0x00000000004092e9 _start
>>> (/home/linux/llvm-7/llvm/build/bin/llvm-dwarfdump+0x4092e9)
>>> Aborted (core dumped)
>>>
>>>
>>> After the google search. It seems that it should be an bug here
>>> https://www.mail-archive.com/llvm-bugs@lists.llvm.org/msg21648.html
>>>
>>> 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
>>>
>>
>> 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)
>>
>> 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.
>>
>> - Dave
>>
>>
>>>
>>> Regards
>>> Muhui
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://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/20181103/70d88e80/attachment.html>