From patchwork Tue Jun 13 00:55:31 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthias Kaehlcke X-Patchwork-Id: 9782911 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 1049B60325 for ; Tue, 13 Jun 2017 00:56:44 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 03283284BF for ; Tue, 13 Jun 2017 00:56:44 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id EBD1E285E9; Tue, 13 Jun 2017 00:56:43 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 807AC284BF for ; Tue, 13 Jun 2017 00:56:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753324AbdFMA4d (ORCPT ); Mon, 12 Jun 2017 20:56:33 -0400 Received: from mail-pg0-f52.google.com ([74.125.83.52]:33109 "EHLO mail-pg0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753241AbdFMA4E (ORCPT ); Mon, 12 Jun 2017 20:56:04 -0400 Received: by mail-pg0-f52.google.com with SMTP id f185so52292276pgc.0 for ; Mon, 12 Jun 2017 17:56:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=Xew9NR72fVUyrZCX7Z13BBE3F4m3Sk9yD5tFZ90X4Ec=; b=iRq/6CU4Ri+tBmwK4DcMH4HjMTj3TERBHIUKPQ48yfcJ/509nHh6WM6I6ukHTvNQrs 2JRoCperbPvLvzQsdL6xp5xX2IEhfGvINPk6rkrG+WR7Tk/97z50aFwjZp5Ms506ydKa EnR13UxTU2eZ3qL4qKY4KhM/aG1wizxylaQDuY2zqr7BElWzWLc6FEU3FMjNmkuh2JwI de8arnh/4ievSazHjyRysqZAm2zfComtOL6P9ujoLnkH8IhiMfD0yLSnRQAt/gVU1GnD wisE3Qkm31INfqA4SRhN3AQ+M7mCQkwjTo3n/nP9gYpD0rYQHaiaVa00Tlt47JFjaxLR eHjA== X-Gm-Message-State: AODbwcCLPxCmDqzM3shinQbVQPEP/C6S8/LRkQ1Pk7fsZmWQ5TSH0447 EoK8TDoVQkVXmCka X-Received: by 10.98.49.198 with SMTP id x189mr56850113pfx.65.1497315363642; Mon, 12 Jun 2017 17:56:03 -0700 (PDT) Received: from mka.mtv.corp.google.com ([172.22.64.162]) by smtp.gmail.com with ESMTPSA id g13sm20658432pgu.54.2017.06.12.17.56.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 12 Jun 2017 17:56:03 -0700 (PDT) From: Matthias Kaehlcke To: Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , "H . J . Lu" , David Woodhouse , Masahiro Yamada , Michal Marek Cc: x86@kernel.org, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, Michael Davidson , Greg Hackmann , Nick Desaulniers , Stephen Hines , Kees Cook , Arnd Bergmann , Bernhard.Rosenkranzer@linaro.org, Peter Foley , Behan Webster , Douglas Anderson , Matthias Kaehlcke Subject: [PATCH 3/3] x86/build: Specify stack alignment for clang Date: Mon, 12 Jun 2017 17:55:31 -0700 Message-Id: <20170613005531.77656-4-mka@chromium.org> X-Mailer: git-send-email 2.13.1.508.gb3defc5cc-goog In-Reply-To: <20170613005531.77656-1-mka@chromium.org> References: <20170613005531.77656-1-mka@chromium.org> Sender: linux-kbuild-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kbuild@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP For gcc stack alignment is configured with -mpreferred-stack-boundary=N, clang has the option -mstack-alignment=N for that purpose. Use the same alignment as for gcc. If the alignment is not specified clang assumes an alignment of 16 bytes, as required by the standard ABI. However as mentioned in d9b0cde91c60 ("x86-64, gcc: Use -mpreferred-stack-boundary=3 if supported") the standard kernel entry on x86-64 leaves the stack on an 8-byte boundary, as a consequence clang will keep the stack misaligned. Signed-off-by: Matthias Kaehlcke --- arch/x86/Makefile | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/arch/x86/Makefile b/arch/x86/Makefile index 86b725d69423..7f6c33f4d428 100644 --- a/arch/x86/Makefile +++ b/arch/x86/Makefile @@ -11,6 +11,14 @@ else KBUILD_DEFCONFIG := $(ARCH)_defconfig endif +# Handle different option names for specifying stack alignment with gcc and +# clang. +ifeq ($(cc-name),clang) + stack_align_opt := -mstack-alignment +else + stack_align_opt := -mpreferred-stack-boundary +endif + # How to compile the 16-bit code. Note we always compile for -march=i386; # that way we can complain to the user if the CPU is insufficient. # @@ -28,7 +36,7 @@ REALMODE_CFLAGS := $(M16_CFLAGS) -g -Os -D__KERNEL__ \ REALMODE_CFLAGS += $(call cc-option-no-kbuild, $(REALMODE_CFLAGS), -ffreestanding) REALMODE_CFLAGS += $(call cc-option-no-kbuild, $(REALMODE_CFLAGS), -fno-stack-protector) -REALMODE_CFLAGS += $(call cc-option-no-kbuild, $(REALMODE_CFLAGS), -mpreferred-stack-boundary=2) +REALMODE_CFLAGS += $(call cc-option-no-kbuild, $(REALMODE_CFLAGS), $(stack_align_opt)=2) export REALMODE_CFLAGS # BITS is used as extension for files which are available in a 32 bit @@ -65,8 +73,8 @@ ifeq ($(CONFIG_X86_32),y) # with nonstandard options KBUILD_CFLAGS += -fno-pic - # prevent gcc from keeping the stack 16 byte aligned - KBUILD_CFLAGS += $(call cc-option,-mpreferred-stack-boundary=2) + # prevent the compiler from keeping the stack 16 byte aligned + KBUILD_CFLAGS += $(call cc-option,$(stack_align_opt)=2) # Disable unit-at-a-time mode on pre-gcc-4.0 compilers, it makes gcc use # a lot more stack due to the lack of sharing of stacklots: @@ -98,8 +106,8 @@ else KBUILD_CFLAGS += $(call cc-option,-mno-80387) KBUILD_CFLAGS += $(call cc-option,-mno-fp-ret-in-387) - # Use -mpreferred-stack-boundary=3 if supported. - KBUILD_CFLAGS += $(call cc-option,-mpreferred-stack-boundary=3) + # Align the stack to 8 bytes if supported. + KBUILD_CFLAGS += $(call cc-option,$(stack_align_opt)=3) # Use -mskip-rax-setup if supported. KBUILD_CFLAGS += $(call cc-option,-mskip-rax-setup)