Re: [llvm-dev] llvm-toolchain-3.8 on lower arm targets, specifically Debian armel and Raspbian.
On 5/17/16 11:07 AM, Tim Northover via llvm-dev wrote:
Hi Peter,
On 16 May 2016 at 22:25, peter green via llvm-dev
<llvm-dev@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
configured.
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 am bad, and I should feel bad... I had it working for v4/v4t and v6m,
but then never set up a buildbot to make sure it stayed working :/ (also
may have failed to upstream the (admittedly simple) patches for it).
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?
Yes, it does:
typedef int (__kernel_cmpxchg_t) (int old, int new, int *ptr);
#define __kernel_cmpxchg (*(__kernel_cmpxchg_t *) 0xffff0fc0)
typedef void (__kernel_dmb_t) (void);
#define __kernel_dmb (*(__kernel_dmb_t *) 0xffff0fa0)
Though there is still an open question of what to do for baremetal,
which of course doesn't have a kernel (though that's a separate issue
from Peter's problems here).
Jon
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.
>
Cheers.
Tim.
_______________________________________________
LLVM Developers mailing list
llvm-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
--
Jon Roelofs
jonathan@codesourcery.com
CodeSourcery / Mentor Embedded
Reply to: