[llvm-dev] llvm-toolchain-3.8 on lower arm targets, specifically Debian armel and Raspbian.
Tim Northover via llvm-dev
llvm-dev at lists.llvm.org
Tue May 17 10:07:19 PDT 2016
On 16 May 2016 at 22:25, peter green via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> I traced this back to code in compiler-rt/lib/builtins/arm/sync-ops.h . The
> comments talk about both arm mode and thumb2 mode code but I only actually
> see thumb2 code in the file. I'm kinda stuck here.
Yes, it looks like we'd need to conditionally compile these functions
in ARM mode and use the v6 barrier instead of dmb ("mcr p15, #0, r0,
c7, c10, #5" I believe) to support the ARM1176JZF-S in RPi. You'd
probably also want the build system to use an explicit -march=armv6 or
something so you're not at the mercy of how the host compiler was
I suspect you're the first person to try and get compiler-rt going for
pre-v7 hardware, which most of us prefer to pretend never happened
most of the time.
> I expect this would be a problem for armel too (though it may go unnoticed
> due to the fact the armel autobuilders now run on armv7 hardware and afaict
> Debian armel unlike raspbian doesn't have any contamination checking in
> place) but the build doesn't even get that far. It fails earlier with.
I'm not even sure where we'd begin for compiler-rt on armel, which
looks like it's supposed to work back to armv4t. That version doesn't
even *have* basic synchronization primitives, though I think I heard
the Linux kernel emulates them at some special restartable address?
The first step would probably be to find out where that is and make
compiler-rt (and/or LLVM directly) use it.
>> /«PKGBUILDDIR»/include/llvm/Support/ThreadPool.h: In member function
>> 'std::shared_future<void> llvm::ThreadPool::async(Function&&, Args&&
I think I encountered similar recently: as I recall libstdc++ just
doesn't support the C++11 thread features LLVM needs on such an old
architecture. I think you'd have to add support before you could build
LLVM (or maybe bootstrap libc++ support). It's likely to be a hard
road either way.
More information about the llvm-dev