Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751578AbdITRo7 (ORCPT ); Wed, 20 Sep 2017 13:44:59 -0400 Received: from terminus.zytor.com ([65.50.211.136]:37077 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751024AbdITRo6 (ORCPT ); Wed, 20 Sep 2017 13:44:58 -0400 Subject: Re: [PATCH 2/2] x86/asm: Fix inline asm call constraints for clang To: Josh Poimboeuf , x86@kernel.org Cc: linux-kernel@vger.kernel.org, Ingo Molnar , Thomas Gleixner , Andy Lutomirski , Linus Torvalds , Alexander Potapenko , Dmitriy Vyukov , Matthias Kaehlcke , Arnd Bergmann , Peter Zijlstra , Andrey Ryabinin References: <31e96e6bcfcb47725e15a093b9c31660dfaad430.1505846562.git.jpoimboe@redhat.com> From: "H. Peter Anvin" Message-ID: Date: Wed, 20 Sep 2017 10:32:43 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <31e96e6bcfcb47725e15a093b9c31660dfaad430.1505846562.git.jpoimboe@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 994 Lines: 28 On 09/19/17 11:45, Josh Poimboeuf wrote: > For inline asm statements which have a CALL instruction, we list the > stack pointer as a constraint to convince GCC to ensure the frame > pointer is set up first: > > static inline void foo() > { > register void *__sp asm(_ASM_SP); > asm("call bar" : "+r" (__sp)) > } > > Unfortunately, that pattern causes clang to corrupt the stack pointer. > > There's actually an easier way to achieve the same goal in GCC, without > causing trouble for clang. If we declare the stack pointer register > variable as a global variable, and remove the constraint altogether, > that convinces GCC to always set up the frame pointer before inserting > *any* inline asm. > > It basically acts as if *every* inline asm statement has a CALL > instruction. It's a bit overkill, but the performance impact should be > negligible. > Again, probably negligible, but why do we need a frame pointer just because we have a call assembly instruction? -hpa