From: Benjamin Berg <benjamin.berg@intel.com>

This patchset is an attempt to start a nolibc port of UML. The goal is
to port UML to use nolibc in smaller chunks to make the switch more
manageable.

There are three parts to this patchset:
 * Two patches to use tools/include headers instead of kernel headers
   for userspace files.
 * A few nolibc fixes and a new NOLIBC_NO_STARTCODE compile flag for it
 * Finally nolibc build support for UML and switching two files while
   adding the appropriate support in nolibc itself.

v1 of this patchset was
  https://lore.kernel.org/all/20250915071115.1429196-1-benjamin@sipsolutions.net/

Changes in v2:
- add sys/uio.h and sys/ptrace.h to nolibc
- Use NOLIBC_NO_RUNTIME to disable nolibc startup code
- Fix out-of-tree build
- various small improvements and cleanups

Should the nolibc changes be merged separately or could everything go
through the same branch?

Also, what about tools/include/linux/compiler.h? It seems that was added
for the tracing code, but it is not clear to me who might ACK that fix.

Benjamin

Benjamin Berg (11):
  tools compiler.h: fix __used definition
  um: use tools/include for user files
  tools/nolibc/stdio: remove perror if NOLIBC_IGNORE_ERRNO is set
  tools/nolibc/dirent: avoid errno in readdir_r
  tools/nolibc: use __fallthrough__ rather than fallthrough
  tools/nolibc: add option to disable runtime
  um: add infrastructure to build files using nolibc
  um: use nolibc for the --showconfig implementation
  tools/nolibc: add uio.h with readv and writev
  tools/nolibc: add ptrace support
  um: switch ptrace FP register access to nolibc

 arch/um/Makefile                             | 38 +++++++++++---
 arch/um/include/shared/init.h                |  2 +-
 arch/um/include/shared/os.h                  |  2 +
 arch/um/include/shared/user.h                |  6 ---
 arch/um/kernel/Makefile                      |  2 +-
 arch/um/kernel/skas/stub.c                   |  1 +
 arch/um/kernel/skas/stub_exe.c               |  4 +-
 arch/um/os-Linux/skas/process.c              |  6 +--
 arch/um/os-Linux/start_up.c                  |  4 +-
 arch/um/scripts/Makefile.rules               | 10 +++-
 arch/x86/um/Makefile                         |  6 ++-
 arch/x86/um/os-Linux/Makefile                |  5 +-
 arch/x86/um/os-Linux/registers.c             | 16 ++----
 arch/x86/um/user-offsets.c                   |  1 -
 tools/include/linux/compiler.h               |  2 +-
 tools/include/nolibc/Makefile                |  2 +
 tools/include/nolibc/arch-arm.h              |  2 +
 tools/include/nolibc/arch-arm64.h            |  2 +
 tools/include/nolibc/arch-loongarch.h        |  2 +
 tools/include/nolibc/arch-m68k.h             |  2 +
 tools/include/nolibc/arch-mips.h             |  2 +
 tools/include/nolibc/arch-powerpc.h          |  2 +
 tools/include/nolibc/arch-riscv.h            |  2 +
 tools/include/nolibc/arch-s390.h             |  2 +
 tools/include/nolibc/arch-sh.h               |  2 +
 tools/include/nolibc/arch-sparc.h            |  2 +
 tools/include/nolibc/arch-x86.h              |  4 ++
 tools/include/nolibc/compiler.h              |  4 +-
 tools/include/nolibc/crt.h                   |  3 ++
 tools/include/nolibc/dirent.h                |  6 +--
 tools/include/nolibc/nolibc.h                |  2 +
 tools/include/nolibc/stackprotector.h        |  2 +
 tools/include/nolibc/stdio.h                 |  2 +
 tools/include/nolibc/stdlib.h                |  2 +
 tools/include/nolibc/sys.h                   |  3 +-
 tools/include/nolibc/sys/auxv.h              |  3 ++
 tools/include/nolibc/sys/ptrace.h            | 52 ++++++++++++++++++++
 tools/include/nolibc/sys/uio.h               | 49 ++++++++++++++++++
 tools/testing/selftests/nolibc/nolibc-test.c | 11 +++++
 39 files changed, 222 insertions(+), 48 deletions(-)
 create mode 100644 tools/include/nolibc/sys/ptrace.h
 create mode 100644 tools/include/nolibc/sys/uio.h

-- 
2.51.0

On Fri, Sep 19, 2025 at 05:34:09PM +0200, Benjamin Berg wrote:
> From: Benjamin Berg <benjamin.berg@intel.com>
> 
> This patchset is an attempt to start a nolibc port of UML.

It would be useful to explain why that is desirable.

On Fri, 2025-09-19 at 08:40 -0700, Christoph Hellwig wrote:
> On Fri, Sep 19, 2025 at 05:34:09PM +0200, Benjamin Berg wrote:
> > From: Benjamin Berg <benjamin.berg@intel.com>
> > 
> > This patchset is an attempt to start a nolibc port of UML.
> 
> It would be useful to explain why that is desirable.

Agree, it should be here, but FWIW it's been discussed elsewhere on the
linux-um list in the past and basically there are various issues around
it. Off the top of my head:
 - glibc enabling new features such as rseq that interact badly with how
   UML manages memory (there were fixes for this, it worked sometimes
   and sometimes not)
 - allocation placement for TLS is problematic (see the SMP series)
 - it's (too) easy to accidentally call glibc functions that require
   huge amounts of stack space

There are probably other reasons, but the mixed nature of UML being both
kernel and "hypervisor" code in a single place doesn't mix well with
glibc.

johannes

Hello Benjamin, Johannes,

On Mon, 22 Sep 2025 16:41:36 +0900,
Johannes Berg wrote:
> 
> On Fri, 2025-09-19 at 08:40 -0700, Christoph Hellwig wrote:
> > On Fri, Sep 19, 2025 at 05:34:09PM +0200, Benjamin Berg wrote:
> > > From: Benjamin Berg <benjamin.berg@intel.com>
> > > 
> > > This patchset is an attempt to start a nolibc port of UML.
> > 
> > It would be useful to explain why that is desirable.
> 
> Agree, it should be here, but FWIW it's been discussed elsewhere on the
> linux-um list in the past and basically there are various issues around
> it. Off the top of my head:
>  - glibc enabling new features such as rseq that interact badly with how
>    UML manages memory (there were fixes for this, it worked sometimes
>    and sometimes not)
>  - allocation placement for TLS is problematic (see the SMP series)
>  - it's (too) easy to accidentally call glibc functions that require
>    huge amounts of stack space
> 
> There are probably other reasons, but the mixed nature of UML being both
> kernel and "hypervisor" code in a single place doesn't mix well with
> glibc.

just curious

- are those issues not happening in other libc implementation ? (e.g.,
  musl-libc)
- same question to nolibc: is there any possibility that nolibc will
  evolve as glibc does, and this evolution introduces the UML issues ?

-- Hajime

On Wed, Sep 24, 2025 at 08:58:47AM +0900, Hajime Tazaki wrote:
> 
> Hello Benjamin, Johannes,
> 
> On Mon, 22 Sep 2025 16:41:36 +0900,
> Johannes Berg wrote:
> > 
> > On Fri, 2025-09-19 at 08:40 -0700, Christoph Hellwig wrote:
> > > On Fri, Sep 19, 2025 at 05:34:09PM +0200, Benjamin Berg wrote:
> > > > From: Benjamin Berg <benjamin.berg@intel.com>
> > > > 
> > > > This patchset is an attempt to start a nolibc port of UML.
> > > 
> > > It would be useful to explain why that is desirable.
> > 
> > Agree, it should be here, but FWIW it's been discussed elsewhere on the
> > linux-um list in the past and basically there are various issues around
> > it. Off the top of my head:
> >  - glibc enabling new features such as rseq that interact badly with how
> >    UML manages memory (there were fixes for this, it worked sometimes
> >    and sometimes not)
> >  - allocation placement for TLS is problematic (see the SMP series)
> >  - it's (too) easy to accidentally call glibc functions that require
> >    huge amounts of stack space
> > 
> > There are probably other reasons, but the mixed nature of UML being both
> > kernel and "hypervisor" code in a single place doesn't mix well with
> > glibc.
> 
> just curious
> 
> - are those issues not happening in other libc implementation ? (e.g.,
>   musl-libc)
> - same question to nolibc: is there any possibility that nolibc will
>   evolve as glibc does, and this evolution introduces the UML issues ?

Nolibc focuses on early boot programs. That does not mean it will never
evolve towrards more generic usage but this remains unlikely, and in any
case there's the goal will remain not to degrade the experience on the
original target (early boot). That doesn't mean there will never be any
breakage but we're doing our best to keep things in a clean and workable
state. Regarding threads, it seems unlikely that they'll arrive any time
soon. But if they did, assuming UML would by then be a long established
user, we'd certainly find a solution together (even via build-time
defines if needed).

Hoping this answers your question.
Willy

On Wed, 2025-09-24 at 05:32 +0200, Willy Tarreau wrote:
> On Wed, Sep 24, 2025 at 08:58:47AM +0900, Hajime Tazaki wrote:
> > 
> > Hello Benjamin, Johannes,
> > 
> > On Mon, 22 Sep 2025 16:41:36 +0900,
> > Johannes Berg wrote:
> > > 
> > > On Fri, 2025-09-19 at 08:40 -0700, Christoph Hellwig wrote:
> > > > On Fri, Sep 19, 2025 at 05:34:09PM +0200, Benjamin Berg wrote:
> > > > > From: Benjamin Berg <benjamin.berg@intel.com>
> > > > > 
> > > > > This patchset is an attempt to start a nolibc port of UML.
> > > > 
> > > > It would be useful to explain why that is desirable.
> > > 
> > > Agree, it should be here, but FWIW it's been discussed elsewhere on the
> > > linux-um list in the past and basically there are various issues around
> > > it. Off the top of my head:
> > >  - glibc enabling new features such as rseq that interact badly with how
> > >    UML manages memory (there were fixes for this, it worked sometimes
> > >    and sometimes not)
> > >  - allocation placement for TLS is problematic (see the SMP series)
> > >  - it's (too) easy to accidentally call glibc functions that require
> > >    huge amounts of stack space
> > > 
> > > There are probably other reasons, but the mixed nature of UML being both
> > > kernel and "hypervisor" code in a single place doesn't mix well with
> > > glibc.
> > 
> > just curious
> > 
> > - are those issues not happening in other libc implementation ? (e.g.,
> >   musl-libc)
> > - same question to nolibc: is there any possibility that nolibc will
> >   evolve as glibc does, and this evolution introduces the UML issues ?
> 
> Nolibc focuses on early boot programs. That does not mean it will never
> evolve towrards more generic usage but this remains unlikely, and in any
> case there's the goal will remain not to degrade the experience on the
> original target (early boot). That doesn't mean there will never be any
> breakage but we're doing our best to keep things in a clean and workable
> state. Regarding threads, it seems unlikely that they'll arrive any time
> soon. But if they did, assuming UML would by then be a long established
> user, we'd certainly find a solution together (even via build-time
> defines if needed).

Also, with nolibc it is really simple to override any functions as
needed. We will likely want to do this for malloc/free so that nothing
bad can happen there.

Actually, UML already tries to do that for glibc. However, it
effectively fails (for dynamically linked builds) because the
dynamically linked glibc still uses its internal version for these
symbols.

Benjamin