From patchwork Tue Jul 11 21:29:40 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthias Kaehlcke X-Patchwork-Id: 9835499 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 9164560325 for ; Tue, 11 Jul 2017 21:30:23 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 7F29A2857F for ; Tue, 11 Jul 2017 21:30:23 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 73608285AD; Tue, 11 Jul 2017 21:30:23 +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=unavailable 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 16BFE285AD for ; Tue, 11 Jul 2017 21:30:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933861AbdGKVaL (ORCPT ); Tue, 11 Jul 2017 17:30:11 -0400 Received: from mail-pg0-f54.google.com ([74.125.83.54]:35263 "EHLO mail-pg0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933857AbdGKVaK (ORCPT ); Tue, 11 Jul 2017 17:30:10 -0400 Received: by mail-pg0-f54.google.com with SMTP id j186so2222942pge.2 for ; Tue, 11 Jul 2017 14:30:09 -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; bh=mn79GCP8ZvMeu8oJMeraoBsX22JUY844LsMjyowq7j0=; b=GaDm79ehVEgeXlIStF2OJWExHcOHxN5L/wzsn79rtwH+c93fkZy8iQKg2bsHpWbcYI XSJKLqm42iZOLGXOKY2+IlbGIirsukCwuLg1p+nzrUxjrYU1OzSuHG53TTCPgj0Sbdi/ a0o+d37O4fLVQ9Z8WNljn2kwrjoD+6JP4uF1pxk+VWl0w5xozSamFCm6ZkEhO1t97HoO +leL0YJ/BnlECdbp7cMJtHB83zr54fFo+5kCigZEguHzUFY+4J10hJnpp/1ywoNV7uE3 T6l8tUzbyUAtHaxMOhwdZXcEZSuwaQ+FZsK7l3mnzdtW0OC9j3vK9C28Znx07jIqtl+u Wtow== X-Gm-Message-State: AIVw110l+oFUCyfwOJQoHwPqbfSpRJAEb69fSqxWN3HfxvQWRtrNfqxL nCZoFl4s8Zane6oM X-Received: by 10.98.155.148 with SMTP id e20mr53325147pfk.149.1499808609121; Tue, 11 Jul 2017 14:30:09 -0700 (PDT) Received: from mka.mtv.corp.google.com ([172.22.64.162]) by smtp.gmail.com with ESMTPSA id b13sm486821pfc.25.2017.07.11.14.30.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 11 Jul 2017 14:30:08 -0700 (PDT) From: Matthias Kaehlcke To: Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , Masahiro Yamada , Michal Marek Cc: x86@kernel.org, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, dianders@chromium.org, Michael Davidson , Greg Hackmann , Nick Desaulniers , Stephen Hines , Kees Cook , Arnd Bergmann , Bernhard.Rosenkranzer@linaro.org, Matthias Kaehlcke Subject: [PATCH] x86/build: Fix stack alignment for clang Date: Tue, 11 Jul 2017 14:29:40 -0700 Message-Id: <20170711212940.101416-1-mka@chromium.org> X-Mailer: git-send-email 2.13.2.725.g09c95d1e9-goog 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 Commit d77698df39a5 ("x86/build: Specify stack alignment for clang") intended to use the same stack alignment for clang as with gcc. The two compilers use different options to configure the stack alignment (gcc: -mpreferred-stack-boundary=n, clang: -mstack-alignment=n). The above commit assumes that the clang option uses the same parameter type as gcc, i.e. that the alignment is specified as 2^n. However clang interprets the value of this option literally to use an alignment of n, in consequence the stack remains misaligned. Change the values used with -mstack-alignment to be the actual alignment instead of a power of two. Signed-off-by: Matthias Kaehlcke --- Apparently I had really bad luck when testing d77698df39a5. It fixed the crash I was investigating and the stack in the debugged function looked good with the patch, so I didn't had any doubt that -mstack-alignment=3 (for x86-64) was the correct solution :( If anyone has suggestions for macro magic to encapsulate the different option name and paramater type I'm happy to adapt the patch. I experimented a bit but didn't find a good solution. arch/x86/Makefile | 15 ++++----------- 1 file changed, 4 insertions(+), 11 deletions(-) diff --git a/arch/x86/Makefile b/arch/x86/Makefile index 1e902f926be3..9c6f11ebf288 100644 --- a/arch/x86/Makefile +++ b/arch/x86/Makefile @@ -11,14 +11,6 @@ else KBUILD_DEFCONFIG := $(ARCH)_defconfig endif -# For gcc stack alignment is specified with -mpreferred-stack-boundary, -# clang has the option -mstack-alignment for that purpose. -ifneq ($(call cc-option, -mpreferred-stack-boundary=4),) - cc_stack_align_opt := -mpreferred-stack-boundary -else ifneq ($(call cc-option, -mstack-alignment=4),) - cc_stack_align_opt := -mstack-alignment -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. # @@ -36,7 +28,8 @@ REALMODE_CFLAGS := $(M16_CFLAGS) -g -Os -D__KERNEL__ \ REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), -ffreestanding) REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), -fno-stack-protector) -REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), $(cc_stack_align_opt)=2) +REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS),\ + -mpreferred-stack-boundary=2,-mstack-alignment=4) export REALMODE_CFLAGS # BITS is used as extension for files which are available in a 32 bit @@ -76,7 +69,7 @@ ifeq ($(CONFIG_X86_32),y) # Align the stack to the register width instead of using the default # alignment of 16 bytes. This reduces stack usage and the number of # alignment instructions. - KBUILD_CFLAGS += $(call cc-option,$(cc_stack_align_opt)=2) + KBUILD_CFLAGS += $(call cc-option,-mpreferred-stack-boundary=2,-mstack-alignment=4) # 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: @@ -115,7 +108,7 @@ else # default alignment which keep the stack *mis*aligned. # Furthermore an alignment to the register width reduces stack usage # and the number of alignment instructions. - KBUILD_CFLAGS += $(call cc-option,$(cc_stack_align_opt)=3) + KBUILD_CFLAGS += $(call cc-option,-mpreferred-stack-boundary=3,-mstack-alignment=8) # Use -mskip-rax-setup if supported. KBUILD_CFLAGS += $(call cc-option,-mskip-rax-setup)