-
Notifications
You must be signed in to change notification settings - Fork 13.2k
Segfault on llvm-rtdyld on ARMv7A (Odroid XU) #18459
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
assigned to @rengolin |
Building LLVM with -O1 or -O2 fixes the problem, so it's something nasty that gcc 4.7.2 is doing on Odroid. If fails in the following code: template if (sizeof(Elf_Ehdr) > FileSize) Header = reinterpret_cast<const Elf_Ehdr *>(base()); ... // Scan sections for special sections. for (Elf_Shdr_Iter SecI = begin_sections(), SecE = end_sections(); ... ec = error_code::success(); Stepping through the disassembled code, I can see that the Buf(Object) happens before the call to base() (which does Buf->getBufferStart()), and that ec's initialization happens before Header's, which is ok, but part of the call to the iterator code, which is inlined, gets executed before Header is initialized, so the base of the pointer operator()-> is 0x0. LLVM's code seems correct, so I think this is just a bug in GCC 4.7.2. I'm not sure I have a way to reduce this case to report it to the GCC list, but we could either revert our GCC version to 4.6.3 (which is working with all other buildbots), or change the CFLAGS to -O2. |
I'm not an Arch expert and I cannot find an easy way to install either gcc 4.6 or 4.8, so I think the interim solution is to change CFLAGS to -O2. |
New error at -O2 with gcc 4.7.2: g++: internal compiler error: Killed (program cc1plus) I'm beginning to think we should not use ODroid XU for buildbots, or we're going to have the same nightmare we had with Pandas, at least not until we can get a different GCC version. At Linaro we use the XU, but the GCC is compiled by hand, from a specific version. I'll see if we can get a binary distribution of it and use it. |
Mikael found the GCC 4.8 we can use (and got his bot green). http://www.archfrog.org/GCC-4.8.2-armv7h His instructions: Install using: pacman -U xxx.pkg.tar.xz Please notice that libtool must be uninstalled prior to installing GCC v4.8.2 (pacman -R libtool); unfortunately my build of libtool was stopped abruptly by a failure in the libtool test case. I have reported this to GNU and am now awaiting their response and/or fix. |
Extended Description
TEST 'LLVM :: DebugInfo/debuglineinfo.test' FAILED
$ llvm-rtdyld -printline test/DebugInfo/Inputs/test-inline.o
Exit Code: 2
Command Output (stderr):
llvm-rtdyld: include/llvm/Object/ELF.h:78: llvm::object::ELFFile::ELFEntityIterator::value_type* llvm::object::ELFFile::ELFEntityIterator::operator->() [with EntT = const llvm::object::Elf_Shdr_Impl<llvm::object::ELFType<(llvm::support::endianness)1u, 8u, true> >; ELFT = llvm::object::ELFType<(llvm::support::endianness)1u, 8u, true>; llvm::object::ELFFile::ELFEntityIterator::pointer = const llvm::object::Elf_Shdr_Impl<llvm::object::ELFType<(llvm::support::endianness)1u, 8u, true> >*; llvm::object::ELFFile::ELFEntityIterator::value_type = const llvm::object::Elf_Shdr_Impl<llvm::object::ELFType<(llvm::support::endianness)1u, 8u, true> >]:
Assertion `Current && "Attempted to dereference an invalid iterator!"' failed.
The text was updated successfully, but these errors were encountered: