Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp15990img; Wed, 27 Mar 2019 15:51:54 -0700 (PDT) X-Google-Smtp-Source: APXvYqx9cTiPfNZnKi030Ryym9wcIS6iE2Yl2ertoBke8ZPh8lru7CCj3C4Ot6IjIm8UUVnXBOIU X-Received: by 2002:aa7:82d9:: with SMTP id f25mr37531776pfn.45.1553727114628; Wed, 27 Mar 2019 15:51:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553727114; cv=none; d=google.com; s=arc-20160816; b=VEBW3MHu6ZFEDMEGo6ai8oOv/ektRu5GwoMqJsuaXgfAEL+RBDsaxhYi6dbicft3On JWR5/p+2WgydPf3+BWYzwcb9svos1oAndjTi7vWnUNmG812xbn8DePir8oPg52uKesVk F+Hxq4F+DnYdkdUdDMv3mCEUuoEnwkqzGt+Bly4g/rtRzdVx7x6y3S568ANSd4qNO+dZ /r6yS0kX5S01ir+bms1bA//uD+Jv4wvlLdCNYiMxWVIytiChjxJtI8FDPsVO4aUw0F1d OFoRPelkH63txYLO0UL/oXdb/kr/Qxele8GDLG3D/kGIv74GxRgyGsz4fSlY2JOmq3IY qCuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=8Kr5H8D1VqHVuUjWO/mvmwyoKvbVB9DyQo2iehFPURM=; b=jhbh7laotb4+zFQa8UKvhKTdsLf0f28lYS/uu+E73vVDus9sQd8rvfZSARY4PDDH9J H7Xs6vXaGTtDbZqxQPIomMtVF+FSqlGnP/FRzc4XBO+GcSeg2fjfUYGZinE9nwfsseLy FTii5qCafheXWY7axY8mv9iBmFODB9nXRiLMjKZVP3ctyQKRyvBTrfkRI2p3AYaVOSOm lBVDFeV4USLtsykJv7QB/t2jZbPBIF08FV1cslRpoqr3QixE1KdE+ICAsk+TOOgWgnXS c6qD1QipdIQod7EfEJuXJ9rSET4XU5augvfNPrSIiDdFwKhBQ6BmeTkDz3EqXw2ibwcm ARRw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f4si19580589pfc.96.2019.03.27.15.51.31; Wed, 27 Mar 2019 15:51:54 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728791AbfC0Wun (ORCPT + 99 others); Wed, 27 Mar 2019 18:50:43 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:51828 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726275AbfC0Wun (ORCPT ); Wed, 27 Mar 2019 18:50:43 -0400 Received: from p5492e2fc.dip0.t-ipconnect.de ([84.146.226.252] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1h9HNV-0003oM-GQ; Wed, 27 Mar 2019 23:50:37 +0100 Date: Wed, 27 Mar 2019 23:50:37 +0100 (CET) From: Thomas Gleixner To: Andi Kleen cc: Andi Kleen , x86@kernel.org, Andrew Morton , LKML , Josh Poimboeuf Subject: Re: [PATCH 02/17] x86, lto: Mark all top level asm statements as .text In-Reply-To: <20190327222914.GX18020@tassilo.jf.intel.com> Message-ID: References: <20190326213803.GN18020@tassilo.jf.intel.com> <20190327005523.bbxxittqf4d5bdz5@two.firstfloor.org> <20190327145918.GU18020@tassilo.jf.intel.com> <20190327154522.GV18020@tassilo.jf.intel.com> <20190327204049.GW18020@tassilo.jf.intel.com> <20190327222914.GX18020@tassilo.jf.intel.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 27 Mar 2019, Andi Kleen wrote: > > > I checked the code general and with the .globl in NATIVE_LABEL the > > > > With or without? I removed that as well. > > With. > > LTO would still need the .globls because the variable and the asm > statement can end up in different assembler files, and resolution > would rely on the linker. This really sucks. As this is a constant source of trouble, we might better bite the bullet and get rid of this fancy macro completely. It's not that we add these patch patterns every other day. So a good old: /* xor %eax %ex */ static const unsigend char patch_qspinlock[] = { 0x31, 0xc0 }; and then in the patch code: return paravirt_patch_insns(ibuf, len, patch_qspinlock, patch_qspinlock + ARRAY_SIZE(patch_qspinlock)); might be less trouble than dealing with that clever inline assembly forever. Thanks, tglx