Re: [RFC PATCH 5/9] tools/nolibc: x86: Add relocation support for x86_64

[Willy Tarreau <w@1wt.eu>]

Hi Daniel,

On Sat, Jan 31, 2026 at 04:44:36PM +0900, Daniel Palmer wrote:
> Add relocation support for x86, both 32bit and 64bit.
> 
> Signed-off-by: Daniel Palmer <daniel@thingy.jp>
> ---
>  tools/include/nolibc/arch-x86.h | 35 +++++++++++++++++++++++++++++++++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/tools/include/nolibc/arch-x86.h b/tools/include/nolibc/arch-x86.h
> index f6c43ac5377b..3639c1104e0d 100644
> --- a/tools/include/nolibc/arch-x86.h
> +++ b/tools/include/nolibc/arch-x86.h
> @@ -7,8 +7,17 @@
>  #ifndef _NOLIBC_ARCH_X86_H
>  #define _NOLIBC_ARCH_X86_H
>  
> +#define NOLIBC_ARCH_HAS_RELOC
> +#if !defined(__x86_64__)
> +#define NOLIBC_ARCH_ELF32
> +#define NOLIBC_ARCH_ELF_REL
> +#elif defined(__x86_64__) && defined(__ILP32__)
> +#define NOLIBC_ARCH_ELF32
> +#endif
> +
>  #include "compiler.h"
>  #include "crt.h"
> +#include "elf.h"
>  
>  #if !defined(__x86_64__)
>  
> @@ -158,6 +167,19 @@
>  })
>  
>  #ifndef NOLIBC_NO_RUNTIME
> +static int __relocate_rel(unsigned long base, elf_rel *entry)
> +{
> +	switch (elf_r_type(entry->r_info)) {
> +	case R_386_RELATIVE:
> +		__relocate_rel_relative(base, entry);
> +		break;
> +	default:
> +		return -1;
> +	}
> +
> +	return 0;
> +}
> +
>  /* startup code */
>  /*
>   * i386 System V ABI mandates:
> @@ -326,6 +348,19 @@ void __attribute__((weak, noreturn)) __nolibc_entrypoint __no_stack_protector _s
>  })
>  
>  #ifndef NOLIBC_NO_RUNTIME
> +static int __relocate_rela(unsigned long base, elf_rela *entry)
> +{
> +	switch (elf_r_type(entry->r_info)) {
> +	case R_AMD64_RELATIVE:

This needs to be conditioned to the definition of this macro, because
now building with the patched nolibc against older UAPI headers just
breaks the build:

../../../include/nolibc/arch-x86.h: In function '__relocate_rela':
../../../include/nolibc/arch-x86.h:354:14: error: 'R_AMD64_RELATIVE' undeclared (first use in this function)
  354 |         case R_AMD64_RELATIVE:
      |              ^~~~~~~~~~~~~~~~

We always take care of keeping support for still maintained kernels, so
right now it's important that uapi headers from 5.10 continue to produce
code that builds and works (which is still the case before the patch).

Willy