tools/nolibc: Add fseek() to stdio.h

A very basic wrapper around lseek() that implements fseek().

Signed-off-by: Daniel Palmer <daniel@thingy.jp>
Link: https://patch.msgid.link/20260105023629.15028

tools/nolibc: Add fseek() to stdio.h

A very basic wrapper around lseek() that implements fseek().

Signed-off-by: Daniel Palmer <daniel@thingy.jp>
Link: https://patch.msgid.link/20260105023629.1502801-3-daniel@thingy.jp
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>

show more ...

tools/nolibc: Add fread() to stdio.h

Add a very basic version of fread() like we already have for fwrite().

Signed-off-by: Daniel Palmer <daniel@thingy.jp>
Link: https://patch.msgid.link/2026010502

tools/nolibc: Add fread() to stdio.h

Add a very basic version of fread() like we already have for fwrite().

Signed-off-by: Daniel Palmer <daniel@thingy.jp>
Link: https://patch.msgid.link/20260105023629.1502801-2-daniel@thingy.jp
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>

show more ...

tools/nolibc: align sys_vfork() with sys_fork()

Currently the generic variants of sys_fork() and sys_vfork() differ in
both they precedence of used system calls and the usage of sys_clone()
vs sys_c

tools/nolibc: align sys_vfork() with sys_fork()

Currently the generic variants of sys_fork() and sys_vfork() differ in
both they precedence of used system calls and the usage of sys_clone()
vs sys_clone3(). While the interface of clone3() in sys_vfork() is more
consistent over different architectures, qemu-user does not support it,
making testing harder. We already handle the different clone()
interfaces for sys_fork() in the architecture-specific headers, and can
do so also for sys_vfork(). In fact SPARC already has such handling and
only s390 is currently missing.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Willy Tarreau <w@1wt.eu>
Link: https://patch.msgid.link/20260104-nolibc-vfork-v1-1-a63464b9e4e6@weissschuh.net

show more ...

selftests/nolibc: add static assertions around time types handling

The nolibc system call wrappers expect the libc types to be compatible
to the kernel types.

Make sure these expectations hold at c

selftests/nolibc: add static assertions around time types handling

The nolibc system call wrappers expect the libc types to be compatible
to the kernel types.

Make sure these expectations hold at compile-time.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Willy Tarreau <w@1wt.eu>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20251220-nolibc-uapi-types-v3-14-c662992f75d7@weissschuh.net

show more ...

tools/nolibc: add __nolibc_static_assert()

Add a wrapper for _Static_assert() to use within nolibc.
While _Static_assert() itself was only standardized in C11,
in GCC and clang dialects it is also a

tools/nolibc: add __nolibc_static_assert()

Add a wrapper for _Static_assert() to use within nolibc.
While _Static_assert() itself was only standardized in C11,
in GCC and clang dialects it is also available in older standards.

Link: https://lore.kernel.org/lkml/20251203192330.GA12995@1wt.eu/
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Willy Tarreau <w@1wt.eu>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20251220-nolibc-uapi-types-v3-13-c662992f75d7@weissschuh.net

show more ...

tools/nolibc: add compiler version detection macros

Some upcoming logic needs to depend on the version of GCC or clang.

Add some helper macros to keep the conditionals readable.

Signed-off-by: Tho

tools/nolibc: add compiler version detection macros

Some upcoming logic needs to depend on the version of GCC or clang.

Add some helper macros to keep the conditionals readable.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Willy Tarreau <w@1wt.eu>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20251220-nolibc-uapi-types-v3-12-c662992f75d7@weissschuh.net

show more ...

tools/nolibc: remove time conversions

Now that 'struct timespec' and 'struct __kernel_timespec' are
compatible, the conversions are not necessary anymore.
The same holds true for 'struct itimerspec'

tools/nolibc: remove time conversions

Now that 'struct timespec' and 'struct __kernel_timespec' are
compatible, the conversions are not necessary anymore.
The same holds true for 'struct itimerspec' and 'struct
__kernel_itimerspec'.

Remove the conversions.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Willy Tarreau <w@1wt.eu>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20251220-nolibc-uapi-types-v3-11-c662992f75d7@weissschuh.net

show more ...

tools/nolibc: always use 64-bit time types

32-bit time types will stop working in 2038.

Switch to 64-bit time types everywhere.

Suggested-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kerne

tools/nolibc: always use 64-bit time types

32-bit time types will stop working in 2038.

Switch to 64-bit time types everywhere.

Suggested-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/lkml/cec27d94-c99d-4c57-9a12-275ea663dda8@app.fastmail.com/
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Willy Tarreau <w@1wt.eu>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20251220-nolibc-uapi-types-v3-9-c662992f75d7@weissschuh.net

show more ...

tools/nolibc: use custom structs timespec and timeval

A custom 'struct timespec' and 'struct timeval' will be necessary for
64-bit time types on 32-bit architectures. <linux/time.h> will define
othe

tools/nolibc: use custom structs timespec and timeval

A custom 'struct timespec' and 'struct timeval' will be necessary for
64-bit time types on 32-bit architectures. <linux/time.h> will define
other time-related types in terms of the custom 'struct timespec'.

Add custom struct definitions which for now mirror exactly the ones from
the UAPI headers, but provide the foundation for further changes.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Willy Tarreau <w@1wt.eu>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20251220-nolibc-uapi-types-v3-8-c662992f75d7@weissschuh.net

show more ...

tools/nolibc/select: avoid libgcc 64-bit multiplications

timeval::tv_usec is going to be 64-bit wide even on 32-bit
architectures. As not all architectures support 64-bit multiplications
instruction

tools/nolibc/select: avoid libgcc 64-bit multiplications

timeval::tv_usec is going to be 64-bit wide even on 32-bit
architectures. As not all architectures support 64-bit multiplications
instructions, calls to libgcc (__multi3()) may be emitted by the
compiler which are not provided by nolibc.

As tv_usec and tv_nsec are guaranteed to always fit into an uint32_t,
perform a 32-bit multiplication instead.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Willy Tarreau <w@1wt.eu>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20251220-nolibc-uapi-types-v3-7-c662992f75d7@weissschuh.net

show more ...

tools/nolibc/gettimeofday: avoid libgcc 64-bit divisions

timespec::tv_nsec is going to be 64-bit wide even on 32-bit
architectures. As not all architectures support 64-bit division
instructions, cal

tools/nolibc/gettimeofday: avoid libgcc 64-bit divisions

timespec::tv_nsec is going to be 64-bit wide even on 32-bit
architectures. As not all architectures support 64-bit division
instructions, calls to libgcc (__divdi3()) may be emitted by the
compiler which are not provided by nolibc.

As tv_nsec is guaranteed to always fit into an uint32_t, perform a
32-bit division instead.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Willy Tarreau <w@1wt.eu>
Link: https://patch.msgid.link/20251220-nolibc-uapi-types-v3-6-c662992f75d7@weissschuh.net

show more ...

tools/nolibc: prefer explicit 64-bit time-related system calls

Make sure to always use the 64-bit safe system calls
in preparation for 64-bit time_t on 32-bit architectures.

Also prevent issues on

tools/nolibc: prefer explicit 64-bit time-related system calls

Make sure to always use the 64-bit safe system calls
in preparation for 64-bit time_t on 32-bit architectures.

Also prevent issues on kernels which disable CONFIG_COMPAT_32BIT_TIME
and therefore don't provide the 32-bit system calls anymore.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Willy Tarreau <w@1wt.eu>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20251220-nolibc-uapi-types-v3-5-c662992f75d7@weissschuh.net

show more ...

tools/nolibc/time: drop invocation of gettimeofday system call

This invocation uses libc types with a system call. While this works
now, upcoming changes to 'struct timeval' would require type
conve

tools/nolibc/time: drop invocation of gettimeofday system call

This invocation uses libc types with a system call. While this works
now, upcoming changes to 'struct timeval' would require type
conversions. If types are converted anyways, the clock_gettime() based
fallback can be used everywhere, simplifying the code.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Willy Tarreau <w@1wt.eu>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20251220-nolibc-uapi-types-v3-4-c662992f75d7@weissschuh.net

show more ...

tools/nolibc/select: drop non-pselect based implementations

These implementations use the libc 'struct timeval' with system calls
which can lead to type mismatches. Currently this is fine, but will

tools/nolibc/select: drop non-pselect based implementations

These implementations use the libc 'struct timeval' with system calls
which can lead to type mismatches. Currently this is fine, but will
break with upcoming changes to 'struct timeval'.

If the structure needs to be converted anyways, the implementations
based on pselect can be used for all architectures. This simplifies the
logic.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Willy Tarreau <w@1wt.eu>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20251220-nolibc-uapi-types-v3-3-c662992f75d7@weissschuh.net

show more ...

tools/nolibc/poll: drop __NR_poll fallback

This fallback is never used, remove it.

Suggested-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/lkml/fbca1d3e-12e4-4c4e-8091-87464035fe3

tools/nolibc/poll: drop __NR_poll fallback

This fallback is never used, remove it.

Suggested-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/lkml/fbca1d3e-12e4-4c4e-8091-87464035fe39@app.fastmail.com/
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Willy Tarreau <w@1wt.eu>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20251220-nolibc-uapi-types-v3-2-c662992f75d7@weissschuh.net

show more ...

tools/nolibc/poll: use kernel types for system call invocations

The system calls expect 'struct __kernel_old_timespec'.
While currently 'struct __kernel_old_timespec' and 'struct timespec' are
compa

tools/nolibc/poll: use kernel types for system call invocations

The system calls expect 'struct __kernel_old_timespec'.
While currently 'struct __kernel_old_timespec' and 'struct timespec' are
compatible, this is confusing. Especially as future patches will change
the definition of 'struct timespec'.

Use the correct kernel type instead.

Suggested-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/lkml/fbca1d3e-12e4-4c4e-8091-87464035fe39@app.fastmail.com/
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Willy Tarreau <w@1wt.eu>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20251220-nolibc-uapi-types-v3-1-c662992f75d7@weissschuh.net

show more ...

tools/nolibc: always use 64-bit mode for s390 header checks

32-bit s390 support was recently removed from nolibc.
If the compiler defaults to 32-bit during the header checks, they fail.

Make sure t

tools/nolibc: always use 64-bit mode for s390 header checks

32-bit s390 support was recently removed from nolibc.
If the compiler defaults to 32-bit during the header checks, they fail.

Make sure to always use 64-bit mode for s390 heafer checks.

Fixes: 169ebcbb9082 ("tools: Remove s390 compat support")
Acked-by: Willy Tarreau <w@1wt.eu>
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Link: https://patch.msgid.link/20251203-nolibc-headers-check-s390-v1-1-5d35e52a83ba@weissschuh.net
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>

show more ...

tools/nolibc: add ptrace support

Add ptrace support, as it will be useful in UML.

Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
[Thomas: drop va_args usage and linux/uio.h inclusion]
Signe

tools/nolibc: add ptrace support

Add ptrace support, as it will be useful in UML.

Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
[Thomas: drop va_args usage and linux/uio.h inclusion]
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>

show more ...