Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp4625047pxb; Tue, 25 Jan 2022 14:51:12 -0800 (PST) X-Google-Smtp-Source: ABdhPJx4tXnUx11R4RhBc3tbEJhsmjXuJ4rLjVjjI3y3qz6bH34vjw33L/EwLf8CHI0ereqOzt8f X-Received: by 2002:a17:902:9001:b0:14a:a1b2:1e6d with SMTP id a1-20020a170902900100b0014aa1b21e6dmr20672296plp.124.1643151072565; Tue, 25 Jan 2022 14:51:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643151072; cv=none; d=google.com; s=arc-20160816; b=t5Bu8/0G9/TCU+CzK5slDxj7Oxdg3h/jOqy8Y75suVtSHprYNyXT2FIOBfCc/8hRsB i2OhKwQ7YWS3HYzkNavKw5Ut0XMBqeTAvNOCKky+IqlGbkBWotw5nirE0bsuRcoRM2La sPwNy6++2TAGLpVV0ZBiXnOgRibFzYSa6tXlbU4ZsVPd3gmxU9tyykIRXZVb94f8NpKF dzKtbjh89lb6MWEu3Q1q5K5O9ro8bMF+4DU2hycKZEwqjm7fYxDH1m8QZlf/HEnS/7u2 uWMaejki7Q6R7e7IjlhBiT+7FyAfxHbYrO3clgE2vLPCdj/h3wIWWVlJO3ydAf1fHP6Z UAUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=AkSgFR7KVS/ybPGgjdz+4teMhA/qI2/I/K23Je1ZVss=; b=Xn5Wd8Z77ITk/FK2Hap/56Gaoq2PAOgBJhl6tYwlJytBZiIxjPuBQmjATwr9bVJYLF 7z1EnI1hur3i2dmpVqIeXdr1O/QUFneKYKrq650jWMOlpywr+a98hIy4dFUIwuZZcfVx mYWYSoBvgw/13MF/rHTgt1hTcMP8jtwbiua5heAT7Yhz2X6iex0Uctsb6pnCk11NJIWC WOK2YViwJvQiS65raIQzomX+u0/NhtCHDT/bCOBBP+osClJ6Y4aKjQMSCmlRJ5xSBtjQ mpdPJfY67BxHZD8q7bzZWUWQOabZT2MjlT7okRvMIAnYoQzS87IhrZxpKhcXHRmmtkz4 5Mwg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a8si105179pfv.253.2022.01.25.14.51.00; Tue, 25 Jan 2022 14:51:12 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350582AbiAYPt2 (ORCPT + 99 others); Tue, 25 Jan 2022 10:49:28 -0500 Received: from foss.arm.com ([217.140.110.172]:51628 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1376525AbiAYPqA (ORCPT ); Tue, 25 Jan 2022 10:46:00 -0500 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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.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.