Hi Sebastian, On 27.11.2015 13:19, Sebastian Andrzej Siewior wrote: > So let me add some of the informations I gathered: > - llvm-3.5 will leave unstable before the release. I've been told today > the chance are exactly zero that it will remain.
I thought so, too. > - I stumbled over https://llvm.org/bugs/show_bug.cgi?id=9605 saying and > I quote "THe MCJIT is working for PPC64 only.". > I'm going to ping him if something changed or will change but it > matches our (or better your) observation. Looking at the crashing code [1] seems to confirm this: void RuntimeDyldELF::resolveRelocation(const SectionEntry &Section, uint64_t Offset, uint64_t Value, uint32_t Type, int64_t Addend, uint64_t SymOffset) { switch (Arch) { case Triple::x86_64: resolveX86_64Relocation(Section, Offset, Value, Type, Addend, SymOffset); break; case Triple::x86: resolveX86Relocation(Section, Offset, (uint32_t)(Value & 0xffffffffL), Type, (uint32_t)(Addend & 0xffffffffL)); break; case Triple::aarch64: case Triple::aarch64_be: resolveAArch64Relocation(Section, Offset, Value, Type, Addend); break; case Triple::arm: // Fall through. case Triple::armeb: case Triple::thumb: case Triple::thumbeb: resolveARMRelocation(Section, Offset, (uint32_t)(Value & 0xffffffffL), Type, (uint32_t)(Addend & 0xffffffffL)); break; case Triple::mips: // Fall through. case Triple::mipsel: resolveMIPSRelocation(Section, Offset, (uint32_t)(Value & 0xffffffffL), Type, (uint32_t)(Addend & 0xffffffffL)); break; case Triple::ppc64: // Fall through. case Triple::ppc64le: resolvePPC64Relocation(Section, Offset, Value, Type, Addend); break; case Triple::systemz: resolveSystemZRelocation(Section, Offset, Value, Type, Addend); break; default: llvm_unreachable("Unsupported CPU type!"); } } As you can see, you can't see 'Triple::ppc' there. This is unchanged for llvm-toolchain-3.7, but llvm-toolchain-snapshot contains [2]: case Triple::ppc: resolvePPC32Relocation(Section, Offset, Value, Type, Addend); break; So I guess that this should be fixed in 3.8, but... > - I was going to check your testcase on llvm-3.7 and snapshots but llvm > failed to build on powerpc. So I can't. ... it fails to build on powerpc. >>> What exactly do we lose if we disable llvm? >> >> I guess the JIT engine is supposed to be faster than the interpreter. > > So no lack of functionality. Does not sound that bad compared to broken > clambc in unstable like we have it right now. Yes. We should just disable llvm on powerpc, at least until llvm 3.8. Best regards, Andreas 1: https://sources.debian.net/src/llvm-toolchain-3.6/1:3.6.2-1/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp/?hl=861#L861 2: https://sources.debian.net/src/llvm-toolchain-snapshot/1:3.8~svn250696-1/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp/?hl=1098#L1098 _______________________________________________ Pkg-clamav-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-clamav-devel
