From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127333 invoked by alias); 15 Oct 2015 09:21:19 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 127322 invoked by uid 89); 15 Oct 2015 09:21:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-oi0-f45.google.com Received: from mail-oi0-f45.google.com (HELO mail-oi0-f45.google.com) (209.85.218.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 15 Oct 2015 09:21:16 +0000 Received: by oiar126 with SMTP id r126so42608362oia.0 for ; Thu, 15 Oct 2015 02:21:14 -0700 (PDT) X-Received: by 10.202.226.206 with SMTP id z197mr4626369oig.19.1444900874189; Thu, 15 Oct 2015 02:21:14 -0700 (PDT) Received: from [172.20.1.109] ([187.188.70.211]) by smtp.gmail.com with ESMTPSA id sm4sm5960265oeb.5.2015.10.15.02.21.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 Oct 2015 02:21:13 -0700 (PDT) References: <561CE769.6050800@partner.samsung.com> <561CE7BA.5070805@partner.samsung.com> <561D3749.8080501@partner.samsung.com> <20151014075410.GU478@tucnak.redhat.com> <561E98E5.5000506@linaro.org> <561F55E3.7010305@samsung.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Cc: Yury Gribov , Evgenii Stepanov , Adhemerval Zanella , "gcc-patches@gcc.gnu.org" From: pinskia@gmail.com Subject: Re: [PATCH 1/7] Libsanitizer merge from upstream r249633. Date: Thu, 15 Oct 2015 09:21:00 -0000 To: Renato Golin X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg01452.txt.bz2 > On Oct 15, 2015, at 1:42 AM, Renato Golin wrote: >=20 >> On 15 October 2015 at 08:29, Yury Gribov wrote: >> Do you have any estimation for when full AArch64 support is ready in LLV= M? >> If it's still months away, I wonder if we may want to enable at least >> current (partial) support for non-Thunder users. >=20 > Hi Yury, >=20 > 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 :). >=20 > However, I can give you an overview of what is done and what is left > to do, so you can have your own judgement. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > For the future, there are still a few things we have to do: >=20 > 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. >=20 > 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 suppo= rt does not exist yet (though it might in next year).=20 So in summary just enable 48 bit va support in the upstream kernel right no= w and not needed to test on thunderx. So please enable 48 bit va in the ker= nel. It is supported on a kernel that supports juno, apm and amd processors= .=20 Note armv8.0 and 8.1 supports up to 48 bit physical addressing and 2 node t= hunderx uses that and that is why 48 bit va is needed for thunderx. Thanks, Andre >=20 > 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. >=20 > Hope that helps. >=20 > cheers, > --renato