[PATCH] aarch64: Set pcrel_off for COFF relocations

[Evgeny Karpov]

Sat Aug 30 2025
Mark Harmstone <mark@harmstone.com> wrote:
> +++ b/bfd/coff-aarch64.c
> @@ -244,7 +244,7 @@ coff_aarch64_secrel_reloc (bfd *abfd,
>  #define HOWTO_INSTALL_ADDEND 1
>  #define HOW(type, right, size, bits, pcrel, left, ovf, func, mask) >    HOWTO (type, right, size, bits, pcrel, left, complain_overflow_##ovf, > -	 coff_aarch64_##func, #type, true, mask, mask, false)
> +	 coff_aarch64_##func, #type, true, mask, mask, true)

It looks like a proper fix. PCRELOFFSET might be a better choice.
For now, this is more about correcting an inactive configuration, as it was
mentioned that this setting is not used in aarch64-w64-mingw32-ld. It
should not impact the relocation implementation in
coff_pe_aarch64_relocate_section.

Mon Sep 1 2025
Mark Harmstone <mark@harmstone.com> wrote:
> Three years on it's not clear to me why we have two ways of doing the same
> relocations in this file: the normal way in coff_pe_aarch64_relocate_section,
> and the HOWTOs for anything unusual.

Most likely, HOWTO did not provide enough flexibility to describe
all relocation needs for aarch64-w64-mingw32. That functionality might
potentially be achieved by extending it.

> Five minutes after sending this patch
> I ran into another two issues in the same area, and I know trying to link
> ELF object files into a PE file is also dangerous.

Linking two different formats does seem dangerous. It might work for simple
cases, but in general, it will require many workarounds and could lead
to unstable results.

> I think once the HOWTOs are fixed the way forward would be to remove
> coff_pe_aarch64_relocate_section and rely on bfd_generic relocation instead -
> that way we don't have untested code here. Unless there's something I'm
> missing about why this would be impossible or a bad idea.

As was mentioned, it might make sense to fix it for correctness. However,
it will not be used for the general purpose until HOWTO is extended to
deprecate coff_pe_aarch64_relocate_section.

Regards,
Evgeny