> On Oct 15, 2015, at 1:42 AM, Renato Golin <renato.go...@linaro.org> wrote: > >> On 15 October 2015 at 08:29, Yury Gribov <y.gri...@samsung.com> wrote: >> Do you have any estimation for when full AArch64 support is ready in LLVM? >> If it's still months away, I wonder if we may want to enable at least >> current (partial) support for non-Thunder users. > > Hi Yury, > > Unfortunately, no. Basic support is there, better support is a few > weeks away (fingers crossed), but full support may take years (and > we're not promising it :). > > However, I can give you an overview of what is done and what is left > to do, so you can have your own judgement. > > Last year, Christophe added ASAN to AArch64, but because of multiple > problems with the tests on environments we didn't have (the official > buildbot was a Juno outside of Linaro), we couldn't enable it by > default. So, support for ASAN and all other sanitizers on AArch64 was > put on hold. Since January this year, we've been studying TSAN, and > realised that there were many shared problems with ASAN, so we decided > to fix the buildbot problem and implement the other sanitizers. > > Fast-forward to today, we have almost all sanitizers "working" on > AArch64. Not all features work (Adhemerval knows more about this), and > it doesn't work on every AArch64 hardware out there, namely those that > we don't have access to. But there are some things that do work, and > they are being tested on every commit since a few months ago. This > means that you can try it out, see what works and what doesn't, and > let us know by creating a bug in LLVM's bugzilla on Compiler-RT. It > doesn't mean we'll fix everything, but it means we'll know what's > broken, so we can plan better. > > One hint to understand the level of support is to look at the tests. > We use two ways of marking tests: XFAIL, as usual, says the test > *must* fail, and normally means (merits aside), that a sanitizer > feature is not implemented, or the test is exclusive for a different > architecture. The other way is by marking it as "REQUIRES: > stable-runtime", which is for tests that fail on some platforms but > not others. This normally means an underlying (internal) sanitizer > feature is not present or too generic, and the test is not good enough > to detect it. None of that is good, we know, but it is what it is, and > as you can imagine, the priority is to get things working first. > > For the future, there are still a few things we have to do: > > 1. Finish adding all the sanitizers. Because they share a lot of code > and execution, enabling one at a time and fixing all the bugs would > make us ignore the problems in all the other SANs, and we'd have to > re-implement a lot again on every new one. Like untangling hair, > working from inside only makes things worse. This would also allow > other people to test the sanitizers that they care about and report > bugs, so we can have a wider view of what's missing and what's broken. > Adhemerval is on the last ones now and we shall have them upstream, > tested (modulo XFAIL), in the next few weeks. > > 2. The first critical issue for AArch64 is the VMA problem and is our > current focus. Some ideas were put forward (including in this thread) > and right now Adhemerval is investigating Jakub's proposal. It > shouldn't take long for us to have a prototype, and we'll share our > findings here as soon as we have it. We'll focus on that problem for > now and only move to the next step once this is resolved and all SAN > tests pass on both 39 and 42 VMA. We don't have 48 or 56, so we'll > rely on you guys (Andrew?) to test the prototype and report back. > Otherwise, we'll assume working on 39/42 is good enough. This should > take another few weeks.
huh? You can get 48 bit va support on any normal aarch64 kernel without my support. It is a standard feature (not enabled by default though). It just happens to be required by thunderx but not unique to thunderx. 52 bit support does not exist yet (though it might in next year). So in summary just enable 48 bit va support in the upstream kernel right now and not needed to test on thunderx. So please enable 48 bit va in the kernel. It is supported on a kernel that supports juno, apm and amd processors. Note armv8.0 and 8.1 supports up to 48 bit physical addressing and 2 node thunderx uses that and that is why 48 bit va is needed for thunderx. Thanks, Andre > > 3. After the VMA issue is resolved, we'll look at clearing the > "stable-runtime" and XFAIL flags from as many tests as possible. > Either by implementing the features, or by improving the tests, or by > moving them into an architecture specific place where they don't get > tested in AArch64 if they don't have to (ex. x86 specific stuff). But > I have to warn you, this will be at a much lower priority than the VMA > issue, and it could take years to finish. Basically, we'll do on a > case by case basis, what people use, what is important, etc. So, no > promises there. But the "product" should be stable enough at this > stage on *what's implemented* that you can use it on your own code. > > Hope that helps. > > cheers, > --renato
