From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 92896 invoked by alias); 13 Oct 2015 09:26:39 -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 92827 invoked by uid 89); 13 Oct 2015 09:26:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 X-HELO: eu-smtp-delivery-143.mimecast.com Received: from eu-smtp-delivery-143.mimecast.com (HELO eu-smtp-delivery-143.mimecast.com) (146.101.78.143) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 13 Oct 2015 09:26:36 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-3-B-fUCPVPS4yfryggFp-Lmg-1; Tue, 13 Oct 2015 10:26:31 +0100 Received: from [10.2.207.27] ([10.1.2.79]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2015 10:26:31 +0100 Subject: Re: [RFC VTV] Fix VTV for targets that have section anchors. To: Ramana Radhakrishnan , "gcc-patches@gcc.gnu.org" References: <56178638.4030601@foss.arm.com> Cc: Caroline Tice From: Marcus Shawcroft Message-ID: <561CCE6C.20503@arm.com> Date: Tue, 13 Oct 2015 09:26:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <56178638.4030601@foss.arm.com> X-MC-Unique: B-fUCPVPS4yfryggFp-Lmg-1 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-SW-Source: 2015-10/txt/msg01202.txt.bz2 On 09/10/15 10:17, Ramana Radhakrishnan wrote: > This started as a Friday afternoon project ... > > It turned out enabling VTV for AArch64 and ARM was a matter of fixing PR6= 7868 which essentially comes from building libvtv with section anchors turn= ed on. The problem was that the flow of control from output_object_block th= rough to switch_section did not have the same special casing for the vtable= section that exists in assemble_variable. > > Once this was done, I managed to build and test aarch64-none-linux-gnu wi= th --enable-vtable-verify, a similar test was done for armhf. > > Testing showed no regressions in the gcc/ g++ testsuites for aarch64 and = armhf > Testing showed no failures in libvtv testsuite for aarch64 but a few more= failures - see below. > Testing showed 2 failures in libstdc++-v3 testsuite compared to without v= table verification. > > FAIL: libstdc++-abi/abi_check > FAIL: experimental/filesystem/iterators/directory_iterator.cc execution t= est > > However both these failures also occur on x86_64 - so I'm content to decl= are victory on AArch64 > as far as basic enablement goes. > > On ARM I see the following failures that I still need to debug - I can se= e that the failure is because the write to _ZN4_VTVI1BE12__vtable_mapE does= not elicit a SEGV but I need to go further than that. > > FAIL: libvtv.cc/thunk_vtable_map_attack.cc -O0 -fvtable-verify=3Dstd exec= ution test > FAIL: libvtv.cc/thunk_vtable_map_attack.cc -O2 -fvtable-verify=3Dstd exec= ution test > FAIL: libvtv.cc/thunk_vtable_map_attack.cc -O0 -fvtable-verify=3Dpreinit = execution test > FAIL: libvtv.cc/thunk_vtable_map_attack.cc -O2 -fvtable-verify=3Dpreinit = execution test > > > Questions - > > 1. Are the generic changes to varasm.c ok ? > 2. Can we take the AArch64 support in now, given this amount of testing ?= Marcus / Caroline ? + aarch64*-*-linux*) + VTV_SUPPORTED=3Dyes ;; Ramana, Go ahead an add the aarch64 enable once you have the=20 pre-requisite varasm changes approved. Cheers /Marcus > 3. Any suggestions / helpful debug hints for VTV debugging (other than tu= rning VTV_DEBUG on and inspecting trace) ? > > There's an arm*-*-* hunk there but I'm easy about applying that right now= and figuring out the issues > over time. In case we don't fix it for 6.0 we can rip the support out bef= ore release. > > > Thanks, > Ramana > > P.S. (Yes, I'll provide a Changelog :) ) >