From: Mark Rutland <mark.rutland@arm.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
acme@redhat.com, Borislav Petkov <bp@alien8.de>,
Mark Brown <broonie@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Josh Poimboeuf <jpoimboe@redhat.com>, Jiri Slaby <jslaby@suse.cz>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Russell King <linux@armlinux.org.uk>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Will Deacon <will@kernel.org>
Subject: Re: [PATCH v2 0/7] linkage: better symbol aliasing
Date: Tue, 25 Jan 2022 15:45:53 +0000 [thread overview]
Message-ID: <YfAbMY6U4UpyrerB@FVFF77S0Q05N> (raw)
In-Reply-To: <CAMj1kXGCFFHzZAqhfmJthGCe6uhFsrHwzK0QyOfrGw7_kNbjWQ@mail.gmail.com>
On Tue, Jan 25, 2022 at 04:28:11PM +0100, Ard Biesheuvel wrote:
> On Tue, 25 Jan 2022 at 12:32, Mark Rutland <mark.rutland@arm.com> 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
next prev parent reply other threads:[~2022-01-25 16:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-25 11:31 [PATCH v2 0/7] linkage: better symbol aliasing Mark Rutland
2022-01-25 11:31 ` [PATCH v2 1/7] arm: lib: remove leading whitespace in bitop macro Mark Rutland
2022-01-25 11:31 ` [PATCH v2 2/7] linkage: add SYM_{ENTRY,START,END}_AT() Mark Rutland
2022-02-10 14:52 ` Mark Rutland
2022-02-11 1:20 ` Nick Desaulniers
2022-02-11 11:32 ` Mark Rutland
2022-02-11 13:24 ` Mark Rutland
2022-01-25 11:31 ` [PATCH v2 3/7] linkage: add SYM_FUNC_ALIAS{,_LOCAL,_WEAK}() Mark Rutland
2022-01-25 11:31 ` [PATCH v2 4/7] arm64: clean up symbol aliasing Mark Rutland
2022-01-25 11:31 ` [PATCH v2 5/7] x86: " Mark Rutland
2022-01-25 11:31 ` [PATCH v2 6/7] linkage: remove SYM_FUNC_{START,END}_ALIAS() Mark Rutland
2022-01-25 11:32 ` [PATCH v2 7/7] tools: update x86 string routines Mark Rutland
2022-01-25 15:28 ` [PATCH v2 0/7] linkage: better symbol aliasing Ard Biesheuvel
2022-01-25 15:45 ` Mark Rutland [this message]
2022-01-25 15:49 ` Ard Biesheuvel
2022-01-25 15:58 ` Mark Rutland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YfAbMY6U4UpyrerB@FVFF77S0Q05N \
--to=mark.rutland@arm.com \
--cc=acme@redhat.com \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=jpoimboe@redhat.com \
--cc=jslaby@suse.cz \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).