For more background see:
https://lore.kernel.org/lkml/20260116122812.2421621-1-daniel@thingy.jp/

Basically I am trying to run normal ELF binaries created with
nolibc on nommu (m68k, 68000). To make this work without an external
linker nolibc needs code to do the relocation.

The following is my attempt at doing this by hacking just enough
together that static-pie binaries work on a few archs.
The ones that work have a patch in this series.

Answers to questions you might have:
Q: Don't we need to handle more relocation types?
A: Maybe, everything exception sparc only had R_x_RELATIVE in
   the nolibc test binary. sparc emits R_SPARC_NONE as well.

Q: Don't we need to make some sections writable for this to
   work.
A: Maybe, I tried to get most of the supported archs working.
   The only one that had relocations on a non-writable section
   was arm64 and I think I can fix it so it doesn't need that.

Q: Why can't you just pass -static-pie to gcc?
A: Only x86 seemed to actually produce static PIE binaries doing
   that. Everything else produced normal static ones. Maybe this
   is a compiler version thing?

There are probably things I'm missing, things I have done totally
wrong. Please feel free to grill me.

Daniel Palmer (9):
  elf: Add relocation types used by nolibc
  tools/nolibc: crt: Split _start_c() into stack-only and normal part
  tools/nolibc: Add basic ELF self-relocation support for static PIE
  tools/nolibc: m68k: Add relocation support
  tools/nolibc: x86: Add relocation support for x86_64
  tools/nolibc: riscv: Add relocation support
  tools/nolibc: arm: Add relocation support
  selftests/nolibc: Add option for building with -static-pie
  fs/binfmt_elf_fdpic: Reflect that PIE binaries also work in KConfig
    help

 fs/Kconfig.binfmt                             |  10 +
 include/uapi/linux/elf-r.h                    |  27 ++
 include/uapi/linux/elf.h                      |   1 +
 tools/include/nolibc/Makefile                 |   1 +
 tools/include/nolibc/arch-arm.h               |  17 ++
 tools/include/nolibc/arch-m68k.h              |  20 +-
 tools/include/nolibc/arch-riscv.h             |  18 ++
 tools/include/nolibc/arch-x86.h               |  35 +++
 tools/include/nolibc/crt.h                    |  62 +++--
 tools/include/nolibc/reloc.h                  | 240 ++++++++++++++++++
 tools/testing/selftests/nolibc/Makefile       |   2 +-
 .../testing/selftests/nolibc/Makefile.nolibc  |   8 +-
 tools/testing/selftests/nolibc/run-tests.sh   |  10 +-
 13 files changed, 423 insertions(+), 28 deletions(-)
 create mode 100644 include/uapi/linux/elf-r.h
 create mode 100644 tools/include/nolibc/reloc.h

-- 
2.51.0

On Sat, Jan 31, 2026 at 04:44:31PM +0900, Daniel Palmer wrote:
> For more background see:
> https://lore.kernel.org/lkml/20260116122812.2421621-1-daniel@thingy.jp/
> 
> Basically I am trying to run normal ELF binaries created with
> nolibc on nommu (m68k, 68000). To make this work without an external
> linker nolibc needs code to do the relocation.
> 
> The following is my attempt at doing this by hacking just enough
> together that static-pie binaries work on a few archs.
> The ones that work have a patch in this series.
> 
> Answers to questions you might have:
> Q: Don't we need to handle more relocation types?
> A: Maybe, everything exception sparc only had R_x_RELATIVE in
>    the nolibc test binary. sparc emits R_SPARC_NONE as well.
> 
> Q: Don't we need to make some sections writable for this to
>    work.
> A: Maybe, I tried to get most of the supported archs working.
>    The only one that had relocations on a non-writable section
>    was arm64 and I think I can fix it so it doesn't need that.
> 
> Q: Why can't you just pass -static-pie to gcc?
> A: Only x86 seemed to actually produce static PIE binaries doing
>    that. Everything else produced normal static ones. Maybe this
>    is a compiler version thing?
> 
> There are probably things I'm missing, things I have done totally
> wrong. Please feel free to grill me.

I'm noticing a significant size increase with this change, and I'm
not sure all of it is well justified:

  $ size nolibc-test-*
     text    data     bss     dec     hex filename
    43300     120     112   43532    aa0c nolibc-test-6.19-rc7
    44524     120     112   44756    aed4 nolibc-test-daniel
  
    => +1.2 kB

Even a trivial "return 0;" program:

  $ size ret0-*      
     text    data     bss     dec     hex filename
    309      24      24     357     165 ret0-6.19-rc7
    642      24      24     690     2b2 ret0-daniel

    => +333 B

The difference I'm seeing is here:

  $ diff -u ret0*size
  --- ret0-6.19-rc7.size  2026-02-01 19:04:33.918536545 +0100
  +++ ret0-daniel.size    2026-02-01 19:04:40.914761767 +0100
  @@ -16,4 +16,5 @@
   0000000000000011 W raise
   0000000000000012 W abort
   0000000000000023 W memmove
  -0000000000000098 W _start_c
  +0000000000000086 W __start_c
  +000000000000015f W _start_c

The delta is indeed 333 bytes.

Is there anything we could detect at build time to detect that we want to
go the heavy way ? Maybe we should only condition that code to __PIE__ ?
There's nothing critical, it's really about having an open discussion on
this, because we're trying to keep the minimal binaries small, and here
we're just doubling the size of the smallest ones all the time.

Thanks!
Willy

Hi Willy,

On Mon, 2 Feb 2026 at 03:14, Willy Tarreau <w@1wt.eu> wrote:
>   $ diff -u ret0*size
>   --- ret0-6.19-rc7.size  2026-02-01 19:04:33.918536545 +0100
>   +++ ret0-daniel.size    2026-02-01 19:04:40.914761767 +0100
>   @@ -16,4 +16,5 @@
>    0000000000000011 W raise
>    0000000000000012 W abort
>    0000000000000023 W memmove
>   -0000000000000098 W _start_c
>   +0000000000000086 W __start_c
>   +000000000000015f W _start_c
>
> The delta is indeed 333 bytes.
>
> Is there anything we could detect at build time to detect that we want to
> go the heavy way ? Maybe we should only condition that code to __PIE__ ?
> There's nothing critical, it's really about having an open discussion on
> this, because we're trying to keep the minimal binaries small, and here
> we're just doubling the size of the smallest ones all the time.
>
> Thanks!
> Willy

Thank you for the feedback. I'll work out a way of hiding all of the
new code unless it's needed.
I think there might still be some increase in size from splitting
_start_c() into two parts though.

Thanks,

Daniel

On Mon, Feb 02, 2026 at 06:45:40AM +0900, Daniel Palmer wrote:
> Hi Willy,
> 
> On Mon, 2 Feb 2026 at 03:14, Willy Tarreau <w@1wt.eu> wrote:
> >   $ diff -u ret0*size
> >   --- ret0-6.19-rc7.size  2026-02-01 19:04:33.918536545 +0100
> >   +++ ret0-daniel.size    2026-02-01 19:04:40.914761767 +0100
> >   @@ -16,4 +16,5 @@
> >    0000000000000011 W raise
> >    0000000000000012 W abort
> >    0000000000000023 W memmove
> >   -0000000000000098 W _start_c
> >   +0000000000000086 W __start_c
> >   +000000000000015f W _start_c
> >
> > The delta is indeed 333 bytes.
> >
> > Is there anything we could detect at build time to detect that we want to
> > go the heavy way ? Maybe we should only condition that code to __PIE__ ?
> > There's nothing critical, it's really about having an open discussion on
> > this, because we're trying to keep the minimal binaries small, and here
> > we're just doubling the size of the smallest ones all the time.
> >
> > Thanks!
> > Willy
> 
> Thank you for the feedback. I'll work out a way of hiding all of the
> new code unless it's needed.
> I think there might still be some increase in size from splitting
> _start_c() into two parts though.

Yes but that's expected. We can spend a few bytes here and there for the
good cause, it's just that here there's an opportunity to avoid most of
them when not needed.

Thanks,
Willy