From: Sam Edwards <cfsworks@gmail.com>
To: u-boot@lists.denx.de
Cc: "Sam Edwards" <CFSworks@gmail.com>,
"Alper Nebi Yasak" <alpernebiyasak@gmail.com>,
"Andrew Scull" <ascull@google.com>,
"Heinrich Schuchardt" <xypron.glpk@gmx.de>,
"Ilias Apalodimas" <ilias.apalodimas@linaro.org>,
"Kever Yang" <kever.yang@rock-chips.com>,
"Marek Behún" <kabel@kernel.org>,
"Michal Simek" <michal.simek@amd.com>,
"Nathan Barrett-Morrison" <nathan.morrison@timesys.com>,
"Pali Rohár" <pali@kernel.org>, "Peng Fan" <peng.fan@nxp.com>,
"Philip Oberfichtner" <pro@denx.de>,
"Philipp Tomsich" <philipp.tomsich@vrull.eu>,
"Quentin Schulz" <quentin.schulz@theobroma-systems.com>,
"Simon Glass" <sjg@chromium.org>, "Tom Rini" <trini@konsulko.com>
Subject: [RFC PATCH 00/10] Improve ARM target's support for LLVM toolchain
Date: Sat, 20 May 2023 14:55:37 -0600 [thread overview]
Message-ID: <20230520205547.1009254-1-CFSworks@gmail.com> (raw)
Here is a series of patches aimed at improving support for the LLVM
toolchain (clang, lld, and to a lesser extent, llvm-objcopy) when
targeting ARM. This toolchain is a cross-compiler "by default" -- a user
generally should not need to install anything more to target their board
of choice if they already have Clang installed. Additionally, Clang has
a few nice diagnostics that should help appreciably with code quality,
if Clang starts to be used regularly by a few more U-Boot developers. ;)
Most of these patches are trivial and as such they should be pretty easy
to review, but the later patches in the patchset start making some
pretty big changes to the linker scripts. There are no behavioral
changes with those (U-Boot should still function the same) but there is
always the risk of compatibility with some third-party tool or loader
being broken. Fortunately, I foresee any problems making themselves
immediately apparent upon testing.
I have tested booting on sunxi/T113, and building for Raspberry Pi
(32-bit and 64-bit). The remaining testing efforts should be focused on:
- Exynos
- EFI loader (esp. on Lenovo X13s, which Heinrich Schuchardt had
mentioned in a previous commit as being fickle)
- Zynq
- Rockchip TPL
- AArch64 SPL
I'm submitting this as an RFC since this doesn't completely guarantee
LLVM toolchain compatibility yet; my focus here is mostly on ensuring
that I haven't caused any regressions in GNU-land. Also, I haven't
discussed most of these changes before doing them. Perhaps alternate
approaches to some of these things can be proposed - I'm all ears.
Outstanding problems are:
- LLD sometimes puts .hash outside of the image binary area, though this
is flagged by binary_size_check
- The main makefile uses --gap-fill=0xff, which is not supported in
llvm-objcopy
- llvm-objcopy also doesn't appear to speak S-Record; the u-boot.srec
target has to be deleted manually
- llvm-objcopy gets upset at some of the EFI code, since the EFI linker
scripts preserve dynamic sections that llvm-objcopy doesn't want to
strip off
Cheers,
Sam
Sam Edwards (10):
makefile: Fix symbol typo in binary_size_check
arm: set alignment properly for asm funcs
arm: exclude eabi_compat from LTO
arm: add __aeabi_memclr in eabi_compat
arm: add aligned-memory aliases to eabi_compat
arm: discard .gnu.version* sections
arm: efi_loader: discard hash, unwind information
arm: efi_loader: move .dynamic out of .text in EFI
arm: discard all .dyn* sections
arm: migrate away from sections.c
Makefile | 2 +-
arch/arm/cpu/armv8/spl_data.c | 4 +-
arch/arm/cpu/armv8/u-boot-spl.lds | 26 ++----
arch/arm/cpu/armv8/u-boot.lds | 48 +++--------
arch/arm/cpu/u-boot.lds | 103 +++++++----------------
arch/arm/include/asm/linkage.h | 4 +-
arch/arm/lib/Makefile | 3 +-
arch/arm/lib/eabi_compat.c | 17 ++++
arch/arm/lib/elf_aarch64_efi.lds | 3 +-
arch/arm/lib/elf_arm_efi.lds | 3 +
arch/arm/lib/sections.c | 36 --------
arch/arm/mach-rockchip/u-boot-tpl-v8.lds | 26 ++----
arch/arm/mach-zynq/u-boot.lds | 73 +++-------------
13 files changed, 96 insertions(+), 252 deletions(-)
delete mode 100644 arch/arm/lib/sections.c
--
2.39.2
next reply other threads:[~2023-05-21 12:33 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-20 20:55 Sam Edwards [this message]
2023-05-20 20:55 ` [RFC PATCH 01/10] makefile: Fix symbol typo in binary_size_check Sam Edwards
2023-05-20 20:55 ` [RFC PATCH 02/10] arm: set alignment properly for asm funcs Sam Edwards
2023-05-20 20:55 ` [RFC PATCH 03/10] arm: exclude eabi_compat from LTO Sam Edwards
2023-05-20 20:55 ` [RFC PATCH 04/10] arm: add __aeabi_memclr in eabi_compat Sam Edwards
2023-05-20 20:55 ` [RFC PATCH 05/10] arm: add aligned-memory aliases to eabi_compat Sam Edwards
2023-05-20 20:55 ` [RFC PATCH 06/10] arm: discard .gnu.version* sections Sam Edwards
2023-05-20 20:55 ` [RFC PATCH 07/10] arm: efi_loader: discard hash, unwind information Sam Edwards
2023-05-22 7:00 ` Ilias Apalodimas
2023-05-22 19:25 ` Sam Edwards
2023-05-22 20:28 ` Ilias Apalodimas
2023-05-23 5:08 ` Heinrich Schuchardt
2023-05-20 20:55 ` [RFC PATCH 08/10] arm: efi_loader: move .dynamic out of .text in EFI Sam Edwards
2023-05-22 7:30 ` Ilias Apalodimas
2023-05-22 8:10 ` Heinrich Schuchardt
2023-05-22 17:13 ` Sam Edwards
2023-05-20 20:55 ` [RFC PATCH 09/10] arm: discard all .dyn* sections Sam Edwards
2023-05-20 20:55 ` [RFC PATCH 10/10] arm: migrate away from sections.c Sam Edwards
2023-05-23 6:56 ` Ilias Apalodimas
2023-05-21 4:26 ` [RFC PATCH 00/10] Improve ARM target's support for LLVM toolchain Heinrich Schuchardt
2023-05-21 4:59 ` Sam Edwards
2023-05-22 6:52 ` Ilias Apalodimas
2023-05-22 19:37 ` Sam Edwards
2023-05-22 20:15 ` Heinrich Schuchardt
2023-05-23 6:54 ` Ilias Apalodimas
2023-05-22 10:39 ` Michal Simek
2023-05-22 15:30 ` Tom Rini
2023-05-22 19:59 ` Sam Edwards
2023-05-22 21:13 ` Tom Rini
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=20230520205547.1009254-1-CFSworks@gmail.com \
--to=cfsworks@gmail.com \
--cc=alpernebiyasak@gmail.com \
--cc=ascull@google.com \
--cc=ilias.apalodimas@linaro.org \
--cc=kabel@kernel.org \
--cc=kever.yang@rock-chips.com \
--cc=michal.simek@amd.com \
--cc=nathan.morrison@timesys.com \
--cc=pali@kernel.org \
--cc=peng.fan@nxp.com \
--cc=philipp.tomsich@vrull.eu \
--cc=pro@denx.de \
--cc=quentin.schulz@theobroma-systems.com \
--cc=sjg@chromium.org \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.de \
/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