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

AArch64 build fails surprisingly close to the end (building sys0.o) #10791

Closed
pao opened this issue Apr 10, 2015 · 31 comments
Closed

AArch64 build fails surprisingly close to the end (building sys0.o) #10791

pao opened this issue Apr 10, 2015 · 31 comments
Labels
arm ARMv7 and AArch64 build Build system, or building Julia or its dependencies

Comments

@pao
Copy link
Member

pao commented Apr 10, 2015

Nexus 9, in a Vivid Vervet (Ubuntu 15.04 beta) chroot.

    JULIA usr/lib/julia/sys0.o
exports.jl
base.jl
reflection.jl
build_h.jl
version_git.jl
julia: /home/android/julia/deps/llvm-3.5.1/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:384: void llvm::RuntimeDyldELF::resolveAArch64Relocation(const
llvm::SectionEntry&, uint64_t, uint64_t, uint32_t, int64_t): Assertion `static_cast<int64_t>(Result) >= (-2147483647-1) && static_cast<int64_t>(Result) <= (4
294967295U)' failed.

signal (6): Aborted
gsignal at /lib/aarch64-linux-gnu/libc.so.6 (unknown line)
Aborted
Makefile:168: recipe for target '/home/android/julia/usr/lib/julia/sys0.o' failed

Make.user

override LLVM_ASSERTIONS=1
LLVM_FLAGS+="--enable-targets=arm --enable-optimized --enable-assertions"

override OPENBLAS_DYNAMIC_ARCH=0
override OPENBLAS_TARGET_ARCH=ARMV8
override USE_BLAS64=0

override LLVM_VER=3.5.1

override USE_SYSTEM_LIBM=1
override USE_SYSTEM_FFTW=1
override USE_SYSTEM_GMP=1
override USE_SYSTEM_MPFR=1
override USE_SYSTEM_LIBUNWIND=1

override OPENBLAS_VER=develop

JCFLAGS += -fsigned-char

Needed system libunwind to pick up aarch64 patches post-1.1 release but applied to the Ubuntu repository. Needed OpenBLAS-develop to pick up this build fix.

Anyone know what LLVM is telling me we've done wrong, here?

@pao pao added build Build system, or building Julia or its dependencies arm ARMv7 and AArch64 labels Apr 10, 2015
@pao
Copy link
Member Author

pao commented Apr 10, 2015

Imma try this with a newer LLVM and see what happens.

@pao
Copy link
Member Author

pao commented Apr 11, 2015

Same error with LLVM 3.6.0.

I missed this earlier, but:

In file included from intrinsics.cpp:50:0,
from codegen.cp:1171:
ccall.cpp:239:4: warning: #warning "ccall is defaulting to llvm ABI, since no platform ABI has been defined for this CPU/OS combination"

I also missed mentioning that you do need a small patch to Make.inc to define aarch64 as "not x86":

diff --git a/Make.inc b/Make.inc
index 7e6310a..22e9bfb 100644
--- a/Make.inc
+++ b/Make.inc
@@ -495,6 +495,8 @@ else ifneq (,$(findstring powerpc,$(ARCH)))
 ISX86=0
 else ifneq (,$(findstring ppc,$(ARCH)))
 ISX86=0
+else ifneq (,$(findstring aarch64,$(ARCH)))
+ISX86=0
 else
 $(error "unknown word-size for arch: $(ARCH)")
 endif

@vtjnash
Copy link
Sponsor Member

vtjnash commented May 12, 2015

what's in /proc/cpuinfo on this machine?

@pao
Copy link
Member Author

pao commented May 26, 2015

(taken from http://newandroidbook.com/Articles/Nexus9.html)

root@flounder:/ # cat /proc/cpuinfo
Processor   : NVIDIA Denver 1.0 rev 0 (aarch64)
processor   : 0
processor   : 1
Features    : fp asimd aes pmull sha1 sha2 crc32 
CPU implementer : 0x4e
CPU architecture: AArch64
CPU variant : 0x0
CPU part    : 0x000
CPU revision    : 0

Hardware    : Flounder
Revision    : 0000
Serial      : 0000000000000000
MTS version : 33410787

@vtjnash
Copy link
Sponsor Member

vtjnash commented May 26, 2015

interesting, this seems to be the first ARM chip that has been attempted that does not have VFP. that means calling convention is probably correct.

@pao
Copy link
Member Author

pao commented May 27, 2015

VFPv3/v4 is apparently pulled into the main instruction set, and NEON is replaced by AdvancedSIMD. I'm not sure why it isn't listed in cpuinfo, though.

Quoting http://people.linaro.org/~rikuvoipio/aarch64-talk/#/17: "VFP/SIMD mandatory - no soft float ABI"

@ViralBShah
Copy link
Member

With the new updates on using the VFP2 calling convention by default, I wonder if this works now.

@pao
Copy link
Member Author

pao commented Jul 19, 2015

Good question; I'll see what I can do.

@ViralBShah
Copy link
Member

Bump. Closing, but reopen if still breaking.

@pao
Copy link
Member Author

pao commented Jul 25, 2015

What? The close is obviously premature.

@pao pao reopened this Jul 25, 2015
@pao
Copy link
Member Author

pao commented Jul 25, 2015

OpenBLAS doesn't build anymore. Yay.

@pao
Copy link
Member Author

pao commented Jul 25, 2015

Switching to system BLAS/LAPACK, looks like the same assertion:

    JULIA usr/lib/julia/inference0.ji
WARNING: unable to determine host cpu name.
essentials.jl
julia: /home/android/julia/deps/llvm-3.6.0/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:346: void llvm::RuntimeDyldELF::resolveAArch64Relocation(const
llvm::SectionEntry&, uint64_t, uint64_t, uint32_t, int64_t): Assertion `static_cast<int64_t>(Result) >= (-2147483647-1) && static_cast<int64_t>(Result) <= (4
294967295U)' failed.

signal (6): Aborted
gsignal at /lib/aarch64-linux-gnu/libc.so.6 (unknown line)
Aborted
Makefile:175: recipe for target '/home/android/julia/usr/lib/julia/inference0.ji' failed
make[1]: *** [/home/android/julia/usr/lib/julia/inference0.ji] Error 134
Makefile:64: recipe for target 'julia-inference' failed
make: *** [julia-inference] Error 2

@Keno
Copy link
Member

Keno commented Jul 25, 2015

Can you try with llvm-svn, this may potentially be fixed there as part of my effort to improve GOT relocations. If not, I'll need to take a look at some point.

@pao
Copy link
Member Author

pao commented Jul 25, 2015

Sure thing.

@pao
Copy link
Member Author

pao commented Jul 26, 2015

Do we build at all on SVN right now?

    CC src/codegen.o
    PERL base/build_h.jl.phony
In file included from intrinsics.cpp:52:0,
                 from codegen.cpp:1255:
ccall.cpp:245:4: warning: #warning "ccall is defaulting to llvm ABI, since no platform ABI has been defined for this CPU/OS combination" [-Wcpp]
 #  warning "ccall is defaulting to llvm ABI, since no platform ABI has been defined for this CPU/OS combination"
    ^
    CC src/disasm.o
In file included from codegen.cpp:516:0:
cgutils.cpp: In function ‘void jl_dump_shadow(char*, int, const char*, size_t, bool)’:
cgutils.cpp:495:30: error: ‘class llvm::TargetMachine’ has no member named ‘getDataLayout’
     clone->setDataLayout(TM->getDataLayout()->getStringRepresentation());
                              ^
disasm.cpp: In function ‘void jl_dump_asm_internal(uintptr_t, size_t, size_t, const llvm::object::ObjectFile*, llvm::raw_ostream&)’:
disasm.cpp:314:83: warning: ‘void llvm::MCObjectFileInfo::InitMCObjectFileInfo(llvm::StringRef, llvm::Reloc::Model, llvm::CodeModel::Model, llvm::MCContext&)
’ is deprecated (declared at /home/android/julia/usr/include/llvm/MC/MCObjectFileInfo.h:192) [-Wdeprecated-declarations]
     MOFI->InitMCObjectFileInfo(TripleName, Reloc::Default, CodeModel::Default, Ctx);
                                                                                   ^
codegen.cpp: In function ‘void jl_init_codegen()’:
codegen.cpp:5542:52: error: ‘class llvm::TargetMachine’ has no member named ‘getDataLayout’
     engine_module->setDataLayout(jl_TargetMachine->getDataLayout()->getStringRepresentation());
                                                    ^
Makefile:80: recipe for target 'codegen.o' failed
make[1]: *** [codegen.o] Error 1
make[1]: *** Waiting for unfinished jobs....
Makefile:58: recipe for target 'julia-src-release' failed
make: *** [julia-src-release] Error 2

@Keno
Copy link
Member

Keno commented Jul 26, 2015

Not anymore apparently. LLVM APIs changed again. Should be straightforward fix, but I'm not currently in a position to do & test it.

@pao
Copy link
Member Author

pao commented Jul 26, 2015

No problem.

@tkelman
Copy link
Contributor

tkelman commented Jul 26, 2015

You can try the release_37 branch of LLVM which should have fewer API changes on it.

@ViralBShah
Copy link
Member

@pao Glad that my premature closing helped revisit the current status.

@pao
Copy link
Member Author

pao commented Jul 26, 2015

A bump would have done the same.

@ViralBShah
Copy link
Member

Sure. My bad.

@pao
Copy link
Member Author

pao commented Jul 26, 2015

Different set of issues on release_37:

In file included from intrinsics.cpp:52:0,
                 from codegen.cpp:1255:
ccall.cpp:245:4: warning: #warning "ccall is defaulting to llvm ABI, since no platform ABI has been defined for this CPU/OS combination" [-Wcpp]
 #  warning "ccall is defaulting to llvm ABI, since no platform ABI has been defined for this CPU/OS combination"
    ^
disasm.cpp: In function ‘void jl_dump_asm_internal(uintptr_t, size_t, size_t, const llvm::object::ObjectFile*, llvm::raw_ostream&)’:
disasm.cpp:314:83: warning: ‘void llvm::MCObjectFileInfo::InitMCObjectFileInfo(llvm::StringRef, llvm::Reloc::Model, llvm::CodeModel::Model, llvm::MCContext&)
’ is deprecated (declared at /home/android/julia/usr/include/llvm/MC/MCObjectFileInfo.h:192) [-Wdeprecated-declarations]
     MOFI->InitMCObjectFileInfo(TripleName, Reloc::Default, CodeModel::Default, Ctx);
                                                                                   ^
codegen.cpp: In function ‘void jl_setup_module(llvm::Module*, bool)’:
codegen.cpp:695:62: error: request for member ‘getStringRepresentation’ in ‘jl_ExecutionEngine->llvm::ExecutionEngine::getDataLayout()’, which is of pointer
type ‘const llvm::DataLayout*’ (maybe you meant to use ‘->’ ?)
         m->setDataLayout(jl_ExecutionEngine->getDataLayout().getStringRepresentation());
                                                              ^
codegen.cpp: In function ‘void jl_init_codegen()’:
codegen.cpp:5558:58: error: request for member ‘getStringRepresentation’ in ‘jl_ExecutionEngine->llvm::ExecutionEngine::getDataLayout()’, which is of pointer
 type ‘const llvm::DataLayout*’ (maybe you meant to use ‘->’ ?)
     m->setDataLayout(jl_ExecutionEngine->getDataLayout().getStringRepresentation());
                                                          ^
codegen.cpp:5559:70: error: request for member ‘getStringRepresentation’ in ‘jl_ExecutionEngine->llvm::ExecutionEngine::getDataLayout()’, which is of pointer
 type ‘const llvm::DataLayout*’ (maybe you meant to use ‘->’ ?)
     engine_module->setDataLayout(jl_ExecutionEngine->getDataLayout().getStringRepresentation());
                                                                      ^
Makefile:80: recipe for target 'codegen.o' failed
make[1]: *** [codegen.o] Error 1
make[1]: *** Waiting for unfinished jobs....
Makefile:58: recipe for target 'julia-src-release' failed
make: *** [julia-src-release] Error 2

@pao
Copy link
Member Author

pao commented Jul 26, 2015

And making the suggested changes in codegen.cpp, we get back to:

    LINK usr/lib/libjulia.so
    JULIA usr/lib/julia/inference0.ji
WARNING: unable to determine host cpu name.
essentials.jl
julia: /home/android/julia/deps/llvm-svn/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:315: void llvm::RuntimeDyldELF::resolveAArch64Relocation(const ll
vm::SectionEntry&, uint64_t, uint64_t, uint32_t, int64_t): Assertion `static_cast<int64_t>(Result) >= (-2147483647-1) && static_cast<int64_t>(Result) <= (429
4967295U)' failed.

signal (6): Aborted
gsignal at /lib/aarch64-linux-gnu/libc.so.6 (unknown line)
Aborted
Makefile:175: recipe for target '/home/android/julia/usr/lib/julia/inference0.ji' failed
make[1]: *** [/home/android/julia/usr/lib/julia/inference0.ji] Error 134
Makefile:64: recipe for target 'julia-inference' failed
make: *** [julia-inference] Error 2

tkelman pushed a commit that referenced this issue Oct 31, 2015
This allows the build to proceed for AArch64 (mentioned in #10791) and others.

(cherry picked from commit f244fb6)
ref #13558
@yuyichao
Copy link
Contributor

Is this an issue on LLVM 3.7. I'm able to get a REPL on AArch64 (ArchLinuxARM) with system LLVM 3.7.0 after applying #14511 and #14500 .

@yuyichao
Copy link
Contributor

yuyichao commented Jan 6, 2016

@pao could you please confirm if this is still an issue for you on the LLVM 3.7.0 or 3.7.1 release? Given that I'm able to get all tests pass on AArch64 apart from libunwind and blas bugs, it's likely that this is fixed before LLVM 3.7.0 is released.

Will close in a few days.

@pao
Copy link
Member Author

pao commented Jan 6, 2016

Quite possible that it would work. I don't have my tablet rooted at the moment, and don't think I'll get around to it in the "a few days" timeframe--but I think your success is probably sufficient to close this.

@pao pao closed this as completed Jan 6, 2016
@tomaklutfu
Copy link
Contributor

Hi. I may have similar issue detailed in the link using LLVM 3.7.0. I added a Make.user file with LLVM=3.7.1 but it still builds LLVM 3.7.0. If not related sorry for the noise. https://groups.google.com/forum/m/#!topic/julia-users/NO6Lox7r_Xc

@tkelman
Copy link
Contributor

tkelman commented Jan 6, 2016

probably need to add override to fix the arm setting

@yuyichao
Copy link
Contributor

yuyichao commented Jan 6, 2016

Your screenshot suggest that you are building for a 32bit ARM so it's unrelated to this issue. In additional to the override, you also need to clear the old build so that it builds a new one.

@eschnett
Copy link
Contributor

eschnett commented Jan 6, 2016

It's LLVM_VER=3.7.1 (with a _VER suffix).

-erik

On Wed, Jan 6, 2016 at 2:51 PM, tomaklutfu notifications@github.com wrote:

Hi. I may have similar issue detailed in the link using LLVM 3.7.0. I
added a Make.user file with LLVM=3.7.1 but it still builds LLVM 3.7.0. If
not related sorry for the noise.
https://groups.google.com/forum/m/#!topic/julia-users/NO6Lox7r_Xc


Reply to this email directly or view it on GitHub
#10791 (comment).

Erik Schnetter schnetter@gmail.com
http://www.perimeterinstitute.ca/personal/eschnetter/

@tomaklutfu
Copy link
Contributor

Thanks all. Yes, I mean LLVM_VER. Issue was 'override' . I'll try building again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
arm ARMv7 and AArch64 build Build system, or building Julia or its dependencies
Projects
None yet
Development

No branches or pull requests

8 participants