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. 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
