From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753150AbdGMTif (ORCPT ); Thu, 13 Jul 2017 15:38:35 -0400 Received: from mail-it0-f45.google.com ([209.85.214.45]:36999 "EHLO mail-it0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752848AbdGMTie (ORCPT ); Thu, 13 Jul 2017 15:38:34 -0400 MIME-Version: 1.0 In-Reply-To: <20170713192554.f4xznyxjkdtrmh3f@treble> References: <20170712212744.23660-1-mka@chromium.org> <20170712221242.puv5illztsla4nph@treble> <20170712222040.GD95735@google.com> <20170712223547.fyra43dizqooosbs@treble> <20170712223630.gb237t4vhrqeu5zd@treble> <20170712232213.GE95735@google.com> <20170713180001.mvwzdmudht56hdk5@treble> <20170713184748.GF95735@google.com> <20170713192554.f4xznyxjkdtrmh3f@treble> From: Michael Davidson Date: Thu, 13 Jul 2017 12:38:32 -0700 Message-ID: Subject: Re: [PATCH] Revert "x86/uaccess: Add stack frame output operand in get_user() inline asm" To: Josh Poimboeuf Cc: Matthias Kaehlcke , Chris J Arges , Borislav Petkov , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , X86 ML , LKML , Douglas Anderson , Greg Hackmann , Nick Desaulniers , Stephen Hines , Kees Cook , Arnd Bergmann , Bernhard.Rosenkranzer@linaro.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 13, 2017 at 12:25 PM, Josh Poimboeuf wrote: > > Anyway this seems like a clang bug to me. If I specify RSP as an input > register then the compiler shouldn't overwrite it first. For that > matter it has no reason to overwrite it if it's an output register > either. > It's certainly a difference in behavior between clang and gcc. My question is whether this particular construct is really a "supported" (or, at least, reasonably guaranteed) way of forcing gcc to create a stack frame if none exists. or whether it is something that "just happens to work". If someone could explain the rationale behind *why* this works the way that it does on gcc that might help convince the clang people that this is actually a bug rather than just a piece of undefined behavior which gcc and clang happen to handle differently.