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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id EA977C433EF for ; Tue, 25 Jan 2022 16:08:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=cYuf6iVzw1JZtoRBPdVI61HoWFpefjviec+qVWe3mBU=; b=y61MkXEwoG0/KE HFjNtYlVUorhki6rsMp867E0gdZ+PugzJoV+JRUoRuUDApSwbIzFxHzfklg7g0THeWFhHGTCCxjhW 4mvLlLkq6hklPyJ26apQ//r3nHU4EQ0JLB6rgERhkP+46fgfu+I+lDvgsW9brjI0n2pnq4l9o07pz 7EDGvZphnDeMV4Fwm3hLHYuqHg61fA50hXU0EyxoaeabF61CHSFWKxuUWfFUNubSuRUby+7AlkBsT mP4bf5VpYMDksCkTJu3/i1X5YB4dILNEUEZwXb6rWyi7NruGHsmg6CubDyTTLFSinilNIMISK3XjA 7kMUsjP+cZIk4W29xRwg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nCOLW-008Yxd-BY; Tue, 25 Jan 2022 16:07:03 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nCO19-008S6u-SV for linux-arm-kernel@lists.infradead.org; Tue, 25 Jan 2022 15:46:01 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A6FB5101E; Tue, 25 Jan 2022 07:45:58 -0800 (PST) Received: from FVFF77S0Q05N (unknown [10.57.1.45]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 318CC3F793; Tue, 25 Jan 2022 07:45:56 -0800 (PST) Date: Tue, 25 Jan 2022 15:45:53 +0000 From: Mark Rutland To: Ard Biesheuvel Cc: Linux Kernel Mailing List , acme@redhat.com, Borislav Petkov , Mark Brown , Catalin Marinas , Dave Hansen , Josh Poimboeuf , Jiri Slaby , Linux ARM , Russell King , Ingo Molnar , Peter Zijlstra , Thomas Gleixner , Will Deacon Subject: Re: [PATCH v2 0/7] linkage: better symbol aliasing Message-ID: References: <20220125113200.3829108-1-mark.rutland@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220125_074559_991654_A90381F9 X-CRM114-Status: GOOD ( 18.51 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Tue, Jan 25, 2022 at 04:28:11PM +0100, Ard Biesheuvel wrote: > On Tue, 25 Jan 2022 at 12:32, Mark Rutland wrote: > > > > This series aims to make symbol aliasing simpler and more consistent. > > The basic idea is to replace SYM_FUNC_START_ALIAS(alias) and > > SYM_FUNC_END_ALIAS(alias) with a new SYM_FUNC_ALIAS(alias, name), so > > that e.g. > > > > SYM_FUNC_START(func) > > SYM_FUNC_START_ALIAS(alias1) > > SYM_FUNC_START_ALIAS(alias2) > > ... asm insns ... > > SYM_FUNC_END(func) > > SYM_FUNC_END_ALIAS(alias1) > > SYM_FUNC_END_ALIAS(alias2) > > EXPORT_SYMBOL(alias1) > > EXPORT_SYMBOL(alias2) > > > > ... can become: > > > > SYM_FUNC_START(name) > > ... asm insns ... > > SYM_FUNC_END(name) > > > > SYM_FUNC_ALIAS(alias1, func) > > EXPORT_SYMBOL(alias1) > > > > SYM_FUNC_ALIAS(alias2, func) > > EXPORT_SYMBOL(alias2) > > > > This avoids repetition and hopefully make it easier to ensure > > consistency (e.g. so each function has a single canonical name and > > associated metadata). > > > > I take it this affects the sizes of the alias ELF symbols? Does that matter? The alias should be given the same size as the original symbol, unless I've made an error. If you look at patch 3: * In SYM_FUNC_START(name), via SYM_ENTRY_AT(name, ...), we create a local label for the start of the function: .L____sym_entry__##name * In SYM_FUNC_END(name), via SYM_END_AT(name, ...), we create a local label for the end of the function: .L____sym_end__##name * In SYM_FUNC_ALIAS*(alias,name), we define the start and end of the alias as the start and end of the original symbol using those local labels, e.g. | #define SYM_FUNC_ALIAS(alias, name) \ | SYM_START_AT(alias, .L____sym_entry__##name, SYM_L_GLOBAL) \ | SYM_END_AT(alias, .L____sym_end__##name, SYM_T_FUNC) Note that: * SYM_FUNC_START() uses SYM_START(), which uses SYM_ENTRY_AT() * SYM_FUNC_END() uses SYM_END(), which uses SYM_END_AT() ... so the definition of tha alias is ultimately structurally identical to the definition of the canoncial name, at least for now. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel