From: Sascha Hauer <s.hauer@pengutronix.de>
To: Ahmad Fatoum <a.fatoum@pengutronix.de>
Cc: BAREBOX <barebox@lists.infradead.org>,
"Claude Sonnet 4.5" <noreply@anthropic.com>
Subject: Re: [PATCH 04/19] ARM: implement elf_apply_relocations() for ELF relocation support
Date: Mon, 5 Jan 2026 20:53:15 +0100 [thread overview]
Message-ID: <aVwWq1BJEMDWT8dq@pengutronix.de> (raw)
In-Reply-To: <6f69f906-bb29-40ad-8a3b-9cb09cb499b3@pengutronix.de>
On Mon, Jan 05, 2026 at 12:58:23PM +0100, Ahmad Fatoum wrote:
> Hi,
>
> On 1/5/26 12:26 PM, Sascha Hauer wrote:
> > Implement architecture-specific ELF relocation handlers for ARM32 and ARM64.
> >
> > ARM32 implementation (arch/arm/lib32/elf_reloc.c):
> > - Handles REL-format relocations (no explicit addend)
> > - Supports R_ARM_RELATIVE and R_ARM_ABS32 relocation types
> > - Addend is read from the target location
> >
> > ARM64 implementation (arch/arm/lib64/elf_reloc.c):
> > - Handles RELA-format relocations (with explicit addend)
> > - Supports R_AARCH64_RELATIVE and R_AARCH64_ABS64 relocation types
> > - Addend is provided in relocation entry
> >
> > Both implementations:
> > - Parse PT_DYNAMIC segment to locate relocation tables
> > - Validate relocation table format and entry sizes
> > - Apply relocations based on the computed load offset
> > - Return appropriate errors for unsupported relocation types
> >
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
> > ---
> > arch/arm/include/asm/elf.h | 11 +++++
> > arch/arm/lib32/Makefile | 1 +
> > arch/arm/lib32/elf_reloc.c | 105 +++++++++++++++++++++++++++++++++++++++++++++
> > arch/arm/lib64/Makefile | 1 +
> > arch/arm/lib64/elf_reloc.c | 105 +++++++++++++++++++++++++++++++++++++++++++++
> > 5 files changed, 223 insertions(+)
> >
> > diff --git a/arch/arm/include/asm/elf.h b/arch/arm/include/asm/elf.h
> > index 4043e6fd5b991eb5cccb3fa0ea28d208006ee1fc..cceb92ee1a5f63c37b0e981c263676bd35a261c0 100644
> > --- a/arch/arm/include/asm/elf.h
> > +++ b/arch/arm/include/asm/elf.h
> > @@ -36,6 +36,17 @@ typedef struct user_fp elf_fpregset_t;
> > #define R_ARM_THM_CALL 10
> > #define R_ARM_THM_JUMP24 30
> >
> > +/* Additional relocation types for dynamic linking */
> > +#define R_ARM_RELATIVE 23
>
> This is already defined in arch/arm/cpu/common.c, you can guess where
> this is going ;)
>
> > +#define R_ARM_GLOB_DAT 21
> > +#define R_ARM_JUMP_SLOT 22
>
> These two are not used.
>
> > +
> > +#define R_AARCH64_NONE 0
> > +#define R_AARCH64_ABS64 257
> > +#define R_AARCH64_RELATIVE 1027
> > +#define R_AARCH64_GLOB_DAT 1025
> > +#define R_AARCH64_JUMP_SLOT 1026
>
> Likewise, only R_AARCH64_JUMP_SLOT and R_AARCH64_GLOB_DAT are not used.
>
> > +/*
> > + * Parse dynamic section and extract relocation info for ARM32
> > + */
> > +static int parse_dynamic_section(struct elf_image *elf, Elf32_Dyn *dyn,
> > + Elf32_Rel **rel_out, u64 *relsz_out)
> > +{
> > + Elf32_Rel *rel = NULL;
>
> If we define ELF_CLASS depending on CONFIG_ARM32/CONFIG_ARM64, we can
> write a generic parse_dynamic_section() that applies to all architectures.
>
> In this case, we would just collect both REL and RELA in the switch and
> just use what's available.
> > +int elf_apply_relocations(struct elf_image *elf, void *dyn_seg)
> > +{
>
> We already have relocate_to_current_adr(). If we change it to call
> a new relocate_image():
>
> relocate_image(get_runtime_offset(),
> runtime_addr(__rel_dyn_start),
> runtime_addr(__rel_dyn_end),
> runtime_addr(__dynsym_start),
> runtime_addr(__dynsym_end));
>
> Then we could use relocate_image() in generic code instead of
> duplicating it per architecture.
>
> > +/*
> > + * Parse dynamic section and extract relocation info for ARM64
> > + */
> > +static int parse_dynamic_section(struct elf_image *elf, Elf64_Dyn *dyn,
> > + Elf64_Rela **rela_out, u64 *relasz_out)
>
> Same comment as for ARM32. I believe this can go into generic code.
>
> > + case R_AARCH64_ABS64:
> > + /* B(P) = S + A */
> > + *fixup_addr = base + rela->r_addend;
> > + break;
>
> What did you do to get R_AARCH64_ABS64 relocations? We don't handle them
> in relocate_to_current_adr() and they shouldn't have been generated.
Likely Claude just generated this for completeness.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2026-01-05 19:53 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-05 11:26 [PATCH 00/19] PBL: Add PBL ELF loading support with dynamic relocations Sascha Hauer
2026-01-05 11:26 ` [PATCH 01/19] elf: Use memcmp to make suitable for PBL Sascha Hauer
2026-01-05 11:46 ` Ahmad Fatoum
2026-01-05 11:26 ` [PATCH 02/19] elf: build for PBL as well Sascha Hauer
2026-01-05 11:26 ` [PATCH 03/19] elf: add dynamic relocation support Sascha Hauer
2026-01-05 14:05 ` Ahmad Fatoum
2026-01-05 11:26 ` [PATCH 04/19] ARM: implement elf_apply_relocations() for ELF " Sascha Hauer
2026-01-05 11:58 ` Ahmad Fatoum
2026-01-05 19:53 ` Sascha Hauer [this message]
2026-01-05 11:26 ` [PATCH 05/19] riscv: " Sascha Hauer
2026-01-05 11:26 ` [PATCH 06/19] elf: implement elf_load_inplace() Sascha Hauer
2026-01-05 13:37 ` Ahmad Fatoum
2026-01-05 22:42 ` Sascha Hauer
2026-01-06 8:18 ` Ahmad Fatoum
2026-01-05 11:26 ` [PATCH 07/19] elf: create elf_open_binary_into() Sascha Hauer
2026-01-05 11:26 ` [PATCH 08/19] Makefile: add barebox.elf build target Sascha Hauer
2026-01-05 12:22 ` Ahmad Fatoum
2026-01-05 15:43 ` Sascha Hauer
2026-01-05 17:11 ` Ahmad Fatoum
2026-01-05 11:26 ` [PATCH 09/19] PBL: allow to link ELF image into PBL Sascha Hauer
2026-01-05 12:11 ` Ahmad Fatoum
2026-01-05 11:26 ` [PATCH 10/19] mmu: add MAP_CACHED_RO mapping type Sascha Hauer
2026-01-05 12:14 ` Ahmad Fatoum
2026-01-05 11:26 ` [PATCH 11/19] mmu: introduce pbl_remap_range() Sascha Hauer
2026-01-05 12:15 ` Ahmad Fatoum
2026-01-06 8:50 ` Ahmad Fatoum
2026-01-06 9:25 ` Sascha Hauer
2026-01-05 11:26 ` [PATCH 12/19] ARM: use relative jumps in exception table Sascha Hauer
2026-01-05 11:44 ` Ahmad Fatoum
2026-01-05 12:29 ` Sascha Hauer
2026-01-05 12:31 ` Ahmad Fatoum
2026-01-05 11:26 ` [PATCH 13/19] ARM: exceptions: make in-binary exception table const Sascha Hauer
2026-01-05 11:26 ` [PATCH 14/19] ARM: linker script: create separate PT_LOAD segments for text, rodata, and data Sascha Hauer
2026-01-05 13:11 ` Ahmad Fatoum
2026-01-05 23:01 ` Sascha Hauer
2026-01-06 7:59 ` Ahmad Fatoum
2026-01-05 11:26 ` [PATCH 15/19] ARM: link ELF image into PBL Sascha Hauer
2026-01-05 12:27 ` Ahmad Fatoum
2026-01-05 11:26 ` [PATCH 16/19] ARM: PBL: setup MMU with proper permissions from ELF segments Sascha Hauer
2026-01-05 12:58 ` Ahmad Fatoum
2026-01-05 11:26 ` [PATCH 17/19] riscv: link ELF image into PBL Sascha Hauer
2026-01-05 13:12 ` Ahmad Fatoum
2026-01-05 11:26 ` [PATCH 18/19] riscv: linker script: create separate PT_LOAD segments for text, rodata, and data Sascha Hauer
2026-01-05 13:40 ` Ahmad Fatoum
2026-01-05 11:27 ` [PATCH 19/19] riscv: add ELF segment-based memory protection with MMU Sascha Hauer
2026-01-05 13:58 ` Ahmad Fatoum
2026-01-05 14:08 ` [PATCH 00/19] PBL: Add PBL ELF loading support with dynamic relocations Ahmad Fatoum
2026-01-05 16:47 ` Sascha Hauer
2026-01-06 8:35 ` Ahmad Fatoum
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=aVwWq1BJEMDWT8dq@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=noreply@anthropic.com \
/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