All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: linux-kernel@vger.kernel.org, catalin.marinas@arm.com,
	will@kernel.org, peterz@infradead.org
Cc: acme@redhat.com, ardb@kernel.org, bp@alien8.de,
	broonie@kernel.org, dave.hansen@linux.intel.com,
	joey.gouly@arm.com, jpoimboe@redhat.com, jslaby@suse.cz,
	linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com,
	mingo@redhat.com, tglx@linutronix.de
Subject: [PATCH v4 0/4] linkage: better symbol aliasing
Date: Wed, 16 Feb 2022 16:22:25 +0000	[thread overview]
Message-ID: <20220216162229.1076788-1-mark.rutland@arm.com> (raw)

Catalin, Will, Peter: I think this is ready now and would like to get it
queued, but it looks like this may (trivially) conflict with other bits
we'll want to queue in either the arm64 tree (Joey's string routine
changes [4]), or tip tree (Peter's IBT series).

I assume the best thing to do would be to have a stable branch merged in
both of those. I've tagged this such that it can be pulled (details
below); Peter also suggested he could make a stable branch in the tip
tree. Any preference?

The usual blurb follows.

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've build-tested the following with both GCC 10.3.0 and LLVM 13.0.0
without issues (ignoring any existing warnings):

* arm omap1_defconfig (v2 broke with LLVM here)
* arm multi_v7_defconfig
* arm64 defconfig
* i386 defconfig
* x86_64 defconfig

I've boot-tested the arm64 Images.

I've pushed the series to my `linkage/alias-rework` branch on git.kernel.org,
atop v5.17-rc2:

  git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git linkage/alias-rework
  https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=linkage/alias-rework

This version is tagged as:

  linkage-alias-rework-20220216.

Since RFCv1 [1]:
* Drop arm64 dma alias removal (taken via arm64 for v5.17-rc1)
* Rename SYM_FUNC_LOCAL_ALIAS() -> SYM_FUNC_ALIAS_LOCAL()
* Update the tools/ copies of x86 routines
* Add preparatory fix for 32-bit arm
* Rebase to v5.17-rc1

Since v2 [2]:
* Rework to be LLVM-compatible
  - Drop SYM_ENTRY_AT() / SYM_END_AT()
  - Drop unnecessary local symbols
  - Calculate size in SYM_END()
  - Use common SYM_ALIAS()
* Drop newly redundant arch/arm changes
* Clarify commit message wording
* Fix typos

Since v3 [3]:
* Update tools/perf/ header copy alongside core header
* Add Josh's Acks
* Fix typos
* Order SYM_FUNC_ALIAS()/SYM_FUNC_ALIAS_LOCAL()/SYM_FUNC_ALIAS() consistently

[1] https://lore.kernel.org/r/20211206124715.4101571-1-mark.rutland@arm.com/
[2] https://lore.kernel.org/r/20220125113200.3829108-1-mark.rutland@arm.com/
[3] https://lore.kernel.org/r/20220211151445.2027553-1-mark.rutland@arm.com/
[4] https://lore.kernel.org/linux-arm-kernel/20220215170723.21266-1-joey.gouly@arm.com/

Thanks,
Mark.

Mark Rutland (4):
  linkage: add SYM_FUNC_ALIAS{,_LOCAL,_WEAK}()
  arm64: clean up symbol aliasing
  x86: clean up symbol aliasing
  linkage: remove SYM_FUNC_{START,END}_ALIAS()

 Documentation/asm-annotations.rst       | 11 ++--
 arch/arm64/include/asm/linkage.h        | 24 ---------
 arch/arm64/kvm/hyp/nvhe/cache.S         |  5 +-
 arch/arm64/lib/clear_page.S             |  5 +-
 arch/arm64/lib/copy_page.S              |  5 +-
 arch/arm64/lib/memchr.S                 |  5 +-
 arch/arm64/lib/memcmp.S                 |  6 +--
 arch/arm64/lib/memcpy.S                 | 21 ++++----
 arch/arm64/lib/memset.S                 | 12 +++--
 arch/arm64/lib/strchr.S                 |  6 ++-
 arch/arm64/lib/strcmp.S                 |  6 +--
 arch/arm64/lib/strlen.S                 |  6 +--
 arch/arm64/lib/strncmp.S                |  6 +--
 arch/arm64/lib/strnlen.S                |  6 ++-
 arch/arm64/lib/strrchr.S                |  5 +-
 arch/arm64/mm/cache.S                   | 35 +++++++------
 arch/x86/boot/compressed/head_32.S      |  3 +-
 arch/x86/boot/compressed/head_64.S      |  3 +-
 arch/x86/crypto/aesni-intel_asm.S       |  4 +-
 arch/x86/lib/memcpy_64.S                | 10 ++--
 arch/x86/lib/memmove_64.S               |  4 +-
 arch/x86/lib/memset_64.S                |  6 +--
 include/linux/linkage.h                 | 67 +++++++++++++------------
 tools/arch/x86/lib/memcpy_64.S          | 10 ++--
 tools/arch/x86/lib/memset_64.S          |  6 +--
 tools/perf/util/include/linux/linkage.h | 52 ++++++++++++-------
 26 files changed, 169 insertions(+), 160 deletions(-)

-- 
2.30.2


WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: linux-kernel@vger.kernel.org, catalin.marinas@arm.com,
	will@kernel.org, peterz@infradead.org
Cc: acme@redhat.com, ardb@kernel.org, bp@alien8.de,
	broonie@kernel.org, dave.hansen@linux.intel.com,
	joey.gouly@arm.com, jpoimboe@redhat.com, jslaby@suse.cz,
	linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com,
	mingo@redhat.com, tglx@linutronix.de
Subject: [PATCH v4 0/4] linkage: better symbol aliasing
Date: Wed, 16 Feb 2022 16:22:25 +0000	[thread overview]
Message-ID: <20220216162229.1076788-1-mark.rutland@arm.com> (raw)

Catalin, Will, Peter: I think this is ready now and would like to get it
queued, but it looks like this may (trivially) conflict with other bits
we'll want to queue in either the arm64 tree (Joey's string routine
changes [4]), or tip tree (Peter's IBT series).

I assume the best thing to do would be to have a stable branch merged in
both of those. I've tagged this such that it can be pulled (details
below); Peter also suggested he could make a stable branch in the tip
tree. Any preference?

The usual blurb follows.

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've build-tested the following with both GCC 10.3.0 and LLVM 13.0.0
without issues (ignoring any existing warnings):

* arm omap1_defconfig (v2 broke with LLVM here)
* arm multi_v7_defconfig
* arm64 defconfig
* i386 defconfig
* x86_64 defconfig

I've boot-tested the arm64 Images.

I've pushed the series to my `linkage/alias-rework` branch on git.kernel.org,
atop v5.17-rc2:

  git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git linkage/alias-rework
  https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=linkage/alias-rework

This version is tagged as:

  linkage-alias-rework-20220216.

Since RFCv1 [1]:
* Drop arm64 dma alias removal (taken via arm64 for v5.17-rc1)
* Rename SYM_FUNC_LOCAL_ALIAS() -> SYM_FUNC_ALIAS_LOCAL()
* Update the tools/ copies of x86 routines
* Add preparatory fix for 32-bit arm
* Rebase to v5.17-rc1

Since v2 [2]:
* Rework to be LLVM-compatible
  - Drop SYM_ENTRY_AT() / SYM_END_AT()
  - Drop unnecessary local symbols
  - Calculate size in SYM_END()
  - Use common SYM_ALIAS()
* Drop newly redundant arch/arm changes
* Clarify commit message wording
* Fix typos

Since v3 [3]:
* Update tools/perf/ header copy alongside core header
* Add Josh's Acks
* Fix typos
* Order SYM_FUNC_ALIAS()/SYM_FUNC_ALIAS_LOCAL()/SYM_FUNC_ALIAS() consistently

[1] https://lore.kernel.org/r/20211206124715.4101571-1-mark.rutland@arm.com/
[2] https://lore.kernel.org/r/20220125113200.3829108-1-mark.rutland@arm.com/
[3] https://lore.kernel.org/r/20220211151445.2027553-1-mark.rutland@arm.com/
[4] https://lore.kernel.org/linux-arm-kernel/20220215170723.21266-1-joey.gouly@arm.com/

Thanks,
Mark.

Mark Rutland (4):
  linkage: add SYM_FUNC_ALIAS{,_LOCAL,_WEAK}()
  arm64: clean up symbol aliasing
  x86: clean up symbol aliasing
  linkage: remove SYM_FUNC_{START,END}_ALIAS()

 Documentation/asm-annotations.rst       | 11 ++--
 arch/arm64/include/asm/linkage.h        | 24 ---------
 arch/arm64/kvm/hyp/nvhe/cache.S         |  5 +-
 arch/arm64/lib/clear_page.S             |  5 +-
 arch/arm64/lib/copy_page.S              |  5 +-
 arch/arm64/lib/memchr.S                 |  5 +-
 arch/arm64/lib/memcmp.S                 |  6 +--
 arch/arm64/lib/memcpy.S                 | 21 ++++----
 arch/arm64/lib/memset.S                 | 12 +++--
 arch/arm64/lib/strchr.S                 |  6 ++-
 arch/arm64/lib/strcmp.S                 |  6 +--
 arch/arm64/lib/strlen.S                 |  6 +--
 arch/arm64/lib/strncmp.S                |  6 +--
 arch/arm64/lib/strnlen.S                |  6 ++-
 arch/arm64/lib/strrchr.S                |  5 +-
 arch/arm64/mm/cache.S                   | 35 +++++++------
 arch/x86/boot/compressed/head_32.S      |  3 +-
 arch/x86/boot/compressed/head_64.S      |  3 +-
 arch/x86/crypto/aesni-intel_asm.S       |  4 +-
 arch/x86/lib/memcpy_64.S                | 10 ++--
 arch/x86/lib/memmove_64.S               |  4 +-
 arch/x86/lib/memset_64.S                |  6 +--
 include/linux/linkage.h                 | 67 +++++++++++++------------
 tools/arch/x86/lib/memcpy_64.S          | 10 ++--
 tools/arch/x86/lib/memset_64.S          |  6 +--
 tools/perf/util/include/linux/linkage.h | 52 ++++++++++++-------
 26 files changed, 169 insertions(+), 160 deletions(-)

-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

             reply	other threads:[~2022-02-16 16:22 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-16 16:22 Mark Rutland [this message]
2022-02-16 16:22 ` [PATCH v4 0/4] linkage: better symbol aliasing Mark Rutland
2022-02-16 16:22 ` [PATCH v4 1/4] linkage: add SYM_FUNC_ALIAS{,_LOCAL,_WEAK}() Mark Rutland
2022-02-16 16:22   ` Mark Rutland
2022-03-09  7:55   ` [tip: x86/core] " tip-bot2 for Mark Rutland
2022-02-16 16:22 ` [PATCH v4 2/4] arm64: clean up symbol aliasing Mark Rutland
2022-02-16 16:22   ` Mark Rutland
2022-03-09  7:55   ` [tip: x86/core] " tip-bot2 for Mark Rutland
2022-02-16 16:22 ` [PATCH v4 3/4] x86: " Mark Rutland
2022-02-16 16:22   ` Mark Rutland
2022-03-09  7:55   ` [tip: x86/core] " tip-bot2 for Mark Rutland
2022-02-16 16:22 ` [PATCH v4 4/4] linkage: remove SYM_FUNC_{START,END}_ALIAS() Mark Rutland
2022-02-16 16:22   ` Mark Rutland
2022-03-09  7:55   ` [tip: x86/core] " tip-bot2 for Mark Rutland
2022-02-17 10:58 ` [PATCH v4 0/4] linkage: better symbol aliasing Peter Zijlstra
2022-02-17 10:58   ` Peter Zijlstra
2022-02-22 10:09   ` Will Deacon
2022-02-22 10:09     ` Will Deacon
2022-02-22 22:40     ` Will Deacon
2022-02-22 22:40       ` Will Deacon
2022-02-22 22:38 ` Will Deacon
2022-02-22 22:38   ` Will Deacon

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=20220216162229.1076788-1-mark.rutland@arm.com \
    --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=joey.gouly@arm.com \
    --cc=jpoimboe@redhat.com \
    --cc=jslaby@suse.cz \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.