From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 435C8C55178 for ; Thu, 29 Oct 2020 13:23:34 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B6ABE2067D for ; Thu, 29 Oct 2020 13:23:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="CvLXvZFp"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="FVzD0xR1" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B6ABE2067D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=7yXd2Ty+c1SJ5uOLl+di7EUttEIU6aMcO+7Z9TFhu0s=; b=CvLXvZFpIzMHilnnsU/NpDhr2 8QUyjYABW6jDV9NSQQMcmry/8wq1VCsU0QNdqemkFcFyqYMWf5nW0pzSJkPiq8cDh+Ebu7bNwzHft J5L7z0UKHXX7B4z0pR2PNz/NQ6S2ZCQzTVEgEOcvbM8AJfK0FzYhJknzjCNrG8QcFIEmNVUDVXm4d JYdtPbGfjApbxcbaa4vVaSmdZtct6lFnL+dT0isBwOVYG3Nw4E6XM3Ld/6+XxfcQVftyWX/g52zn0 bbdfr/50so0dElpiMLMn8iAKYf5QzQBI3v7gBu3dRpFPwlFX8eMljZtvoWtlH5EJjG+KVAZMebq3U GFWsbhErw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kY7sz-00041g-DG; Thu, 29 Oct 2020 13:22:37 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kY7sv-0003zt-1V for linux-arm-kernel@lists.infradead.org; Thu, 29 Oct 2020 13:22:34 +0000 Received: from mail-ot1-f45.google.com (mail-ot1-f45.google.com [209.85.210.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8ADB02067D for ; Thu, 29 Oct 2020 13:22:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603977751; bh=LhX92dN5SonP2G/jtEvAw5huCLAlxbDLCBDvukK6Cp8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=FVzD0xR1P123T1bb6ov0EXfP+tBIBYyugpVtmB0VK+CRcMgDMLFpjlmGSRONyCa++ h5O6A4kzczy7UWlQKjlttcAw5GRkOaouaeqIN5tl0ajUNb/wvKkJD0M1TMZfXnLX87 BYPH+l+t/i/zmLZjfenPXKUfwtcmMrTQ1WQiqjTQ= Received: by mail-ot1-f45.google.com with SMTP id m26so2178578otk.11 for ; Thu, 29 Oct 2020 06:22:31 -0700 (PDT) X-Gm-Message-State: AOAM532W4FNpom1jnIrtLpSzDskcOv5TfwfX35HK/YTrw4v5GQ+2ojaQ T4VqtU/C4Hu3j3x1SM0DahMEf/3yAwY4g4qUrrc= X-Google-Smtp-Source: ABdhPJyQJweZzhKwb8/8PYXM2/+9SE7gIY6040SoaGeYWaFE+Wtvyz+PNNDVRcfO+CVnm3xvLEFXO5LphgLy1Tgdqho= X-Received: by 2002:a05:6830:1f13:: with SMTP id u19mr3129771otg.108.1603977750741; Thu, 29 Oct 2020 06:22:30 -0700 (PDT) MIME-Version: 1.0 References: <20201028184114.6834-1-ardb@kernel.org> <20201029112747.GA4090840@google.com> <20201029115442.GA4092571@google.com> In-Reply-To: <20201029115442.GA4092571@google.com> From: Ard Biesheuvel Date: Thu, 29 Oct 2020 14:22:19 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] arm64: implement support for static call trampolines To: Quentin Perret X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201029_092233_355433_ABB218A2 X-CRM114-Status: GOOD ( 27.33 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Peter Zijlstra , Catalin Marinas , James Morse , Will Deacon , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 29 Oct 2020 at 12:54, Quentin Perret wrote: > > On Thursday 29 Oct 2020 at 12:32:50 (+0100), Ard Biesheuvel wrote: > > We'll need tooling along the lines of the GCC plugin I wrote [0] to > > implement inline static calls - doing function calls from inline > > assembly is too messy, too fragile and too error prone to rely on. > > Right, and that is the gut feeling I had too, but I can't quite put my > finger on what exactly can go wrong. Any pointers? > The main problem is that the compiler is not aware that a function call is being made. For instance, this code int fred(int l) { asm("bl barney" :"+r"(l) ::"x1", "x2", "x3", "x4", "x5", "x6", "x7", "x8", "x9", "x10", "x11", "x12", "x13", "x14", "x15", "x16", "x17", "x30", "cc"); return l + 1; } works with GCC, but only if I omit the x29 clobber, or it gives an error. With that omitted, Clang produces .type fred,@function fred: // @fred // %bb.0: str x30, [sp, #-16]! // 8-byte Folded Spill //APP bl barney //NO_APP add w0, w0, #1 // =1 ldr x30, [sp], #16 // 8-byte Folded Reload ret i.e., it does not set up the stack frame correctly, and so we lose the ability to unwind the stack through this call. There may be some other corner cases, although I agree it makes sense to get to the bottom of this. > > However, as I discussed with Will offline yesterday as well, the > > question that got snowed under is whether we need any of this on arm64 > > in the first place. It seems highly unlikely that inline static calls > > are worth it, and even out-of-line static calls are probably not worth > > the hassle as we don't have the retpoline problem. > > > > So this code should be considered an invitation for discussion, and > > perhaps someone can invent a use case where benchmarks can show a > > worthwhile improvement. But let's not get ahead of ourselves. > > The reason I'm interested in this is because Android makes heavy use of > trace points/hooks, so any potential improvement in this area would be > welcome. Now I agree we need numbers to show the benefit is real before > this can be considered for inclusion in the kernel. I'll try and see if > we can get something. > > Thanks, > Quentin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel