Skip to content
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

Segfault on llvm-rtdyld on ARMv7A (Odroid XU) #18459

Closed
rengolin opened this issue Nov 29, 2013 · 5 comments
Closed

Segfault on llvm-rtdyld on ARMv7A (Odroid XU) #18459

rengolin opened this issue Nov 29, 2013 · 5 comments
Assignees
Labels
bugzilla Issues migrated from bugzilla mc Machine (object) code

Comments

@rengolin
Copy link
Member

Bugzilla Link 18085
Resolution FIXED
Resolved on Dec 01, 2013 11:57
Version trunk
OS Linux

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.

@rengolin
Copy link
Member Author

assigned to @rengolin

@rengolin
Copy link
Member Author

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
ELFFile::ELFFile(MemoryBuffer *Object, error_code &ec)
: Buf(Object),
...
dt_soname(0) {
const uint64_t FileSize = Buf->getBufferSize();

if (sizeof(Elf_Ehdr) > FileSize)
// FIXME: Proper error handling.
report_fatal_error("File too short!");

Header = reinterpret_cast<const Elf_Ehdr *>(base());

...

// Scan sections for special sections.

for (Elf_Shdr_Iter SecI = begin_sections(), SecE = end_sections();
SecI != SecE; ++SecI) {

...

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.

@rengolin
Copy link
Member Author

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.

@rengolin
Copy link
Member Author

rengolin commented Dec 1, 2013

New error at -O2 with gcc 4.7.2:

g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See https://bugs.archlinux.org/ for instructions.
/home/user/devel/buildbot/localbot/clang-native-arm-cortex-a15-arch/llvm/Makefile.rules:1464: recipe for target '/home/user/devel/buildbot/localbot/clang-native-arm-cortex-a15-arch/llvm/tools/clang/unittests/Tooling/Release+Asserts/RecursiveASTVisitorTest.o' failed
make[4]: *** [/home/user/devel/buildbot/localbot/clang-native-arm-cortex-a15-arch/llvm/tools/clang/unittests/Tooling/Release+Asserts/RecursiveASTVisitorTest.o] Error 1

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.

@rengolin
Copy link
Member Author

rengolin commented Dec 1, 2013

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.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 9, 2021
@Endilll Endilll added mc Machine (object) code and removed object labels Aug 15, 2023
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla mc Machine (object) code
Projects
None yet
Development

No branches or pull requests

2 participants