From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1393 invoked by alias); 30 Aug 2017 05:21:30 -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 128940 invoked by uid 89); 30 Aug 2017 05:19:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy= X-HELO: mail-qt0-f174.google.com Received: from mail-qt0-f174.google.com (HELO mail-qt0-f174.google.com) (209.85.216.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 30 Aug 2017 05:19:20 +0000 Received: by mail-qt0-f174.google.com with SMTP id h15so8051098qta.4 for ; Tue, 29 Aug 2017 22:19:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=K2VLbIlxI1R/eLg5aabTGvC6Yu3ilplOQNrLTYrqb2Y=; b=L7J0+aiCN/cD+peCBoVywNBSDdTo7HQTZiITkyCJAt0UjUUNbmn8ucpB5I0Wgv0Mwn q0CwS2TeRYK+KuYEN176lsxTNBx1gd6mih9pmHrokIh23D4QjEo/95l30J39wPWJ1Ccs kHwng2tQK00NATQpLuGhZUK71vXcNlOe8qKpdhxiBhL2U48JEpxt69IywXaVSpDT4804 Y2bNLRYmu5PFkCcLVFXhsNXY3avUu/0kCvh2J4tVvkbYK54lc/4YxH/S5iucfepoIoDa jjf7qIlHNitFIZwbZ1eb0nfBqFkKaxT777eE9lZ0dMx8hUJlkyUCGIa24LNLJfnhQA+T WK+w== X-Gm-Message-State: AHYfb5iHH6RsCvu7V/oTsAYhC10zvW2pFc8fG4w8zi77il00GDM+LBwv KBlVEE6sMNpBpIKp7UgUgcoQfJ+AxFLf X-Received: by 10.237.61.116 with SMTP id h49mr386183qtf.195.1504070358563; Tue, 29 Aug 2017 22:19:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.49.6 with HTTP; Tue, 29 Aug 2017 22:19:18 -0700 (PDT) In-Reply-To: <20170829113141.GA18078@arm.com> References: <20170829113141.GA18078@arm.com> From: Kugan Vivekanandarajah Date: Wed, 30 Aug 2017 09:05:00 -0000 Message-ID: Subject: Re: [AARCH64] Disable pc relative literal load irrespective of TARGET_FIX_ERR_A53_84341 To: James Greenhalgh Cc: "gcc-patches@gcc.gnu.org" , Richard Earnshaw , nd Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg01696.txt.bz2 Hi James, On 29 August 2017 at 21:31, James Greenhalgh wrote: > On Tue, Jun 27, 2017 at 11:20:02AM +1000, Kugan Vivekanandarajah wrote: >> https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00614.html added this >> workaround to get kernel building with when TARGET_FIX_ERR_A53_843419 >> is enabled. >> >> This was added to support building kernel loadable modules. In kernel, >> when CONFIG_ARM64_ERRATUM_843419 is selected, the relocation needed >> for ADRP/LDR (R_AARCH64_ADR_PREL_PG_HI21 and >> R_AARCH64_ADR_PREL_PG_HI21_NC are removed from the kernel to avoid >> loading objects with possibly offending sequence). Thus, it could only >> support pc relative literal loads. >> >> However, the following patch was posted to kernel to add >> -mpc-relative-literal-loads >> http://www.spinics.net/lists/arm-kernel/msg476149.html >> >> -mpc-relative-literal-loads is unconditionally added to the kernel >> build as can be seen from: >> https://github.com/torvalds/linux/blob/master/arch/arm64/Makefile >> >> Therefore this patch removes the hunk so that applications like >> SPECcpu2017's 521/621.wrf can be built (with LTO in this case) without >> -mno-pc-relative-literal-loads >> >> Bootstrapped and regression tested on aarch64-linux-gnu with no new regressions. >> >> Is this OK for trunk? > > Hi Kugan, > > I'm struggling a little to convince myself that this is correct. I think > the argument is that this was a workaround for one very particular issue > with the linux kernel module loader, which hard faults by refusing to > handle these relocations when in a workaround mode for Erratum 843419. Yes. > Most of these relocations won't occur because the kernel builds with > -mcmodel=large, but literals would always use a small model style > adrp/load, unless we were using -mpc-relative-literal-loads . So, this > workaround enabled -mpc-relative-literal-loads always when we were in > a workaround mode, thus allowing the kernel loader to continue. > > The argument for removing it then, is that with the kernel now always using > -mpc-relative-literal-loads there is no reason for this workaround to stay > in place. The linkers which we will use will apply the workaround if needed. Yes. > Testcases and a detailed problem report of the build failures you had seen in > 521.wrf would have helped me get closer to understanding this, and made > review substantially easier. Sorry for not being clear with this. Unfortunately 521.wrf was showing this error with LTO so I could not reproduce with a small enough test case. > Am I on the right track? > > If so, this is OK for trunk. If not, please can you expand on what is going > on in this patch. Thanks for the review. Kugan > > Thanks, > James > > >> >> Thanks, >> Kugan >> >> gcc/testsuite/ChangeLog: >> >> 2017-06-27 Kugan Vivekanandarajah >> >> * gcc.target/aarch64/pr63304_1.c: Remove-mno-fix-cortex-a53-843419. >> >> gcc/ChangeLog: >> >> 2017-06-27 Kugan Vivekanandarajah >> >> * config/aarch64/aarch64.c (aarch64_override_options_after_change_1): >> Disable pc relative literal load irrespective of TARGET_FIX_ERR_A53_84341 >> for default. > >