On 2025-09-15 11:09:40+0000, Berg, Benjamin wrote: > On Mon, 2025-09-15 at 11:07 +0200, Thomas Weißschuh wrote: > > On 2025-09-15 09:11:15+0200, Benjamin Berg wrote: > > > From: Benjamin Berg <benjamin.b...@intel.com> > > > > > > The registers.c file only contain the routines for floating point > > > register access in ptrace mode and initial size detection. The file can > > > be moved over to nolibc by replacing the ptrace libc call with a simple > > > wrapper that does a direct syscall. > > > > > > Signed-off-by: Benjamin Berg <benjamin.b...@intel.com> > > > --- > > > arch/x86/um/os-Linux/Makefile | 5 ++++- > > > arch/x86/um/os-Linux/registers.c | 22 ++++++++-------------- > > > 2 files changed, 12 insertions(+), 15 deletions(-) > > > > > > diff --git a/arch/x86/um/os-Linux/Makefile b/arch/x86/um/os-Linux/Makefile > > > index 77a308aaa5ec..d37320430822 100644 > > > --- a/arch/x86/um/os-Linux/Makefile > > > +++ b/arch/x86/um/os-Linux/Makefile > > > @@ -3,10 +3,13 @@ > > > # Licensed under the GPL > > > # > > > > > > -obj-y = registers.o mcontext.o > > > +obj-y = mcontext.o > > > > > > obj-$(CONFIG_X86_32) += tls.o > > > > > > USER_OBJS := $(obj-y) > > > > > > +obj-y += registers.o > > > +NOLIBC_OBJS := registers.o > > > + > > > include $(srctree)/arch/um/scripts/Makefile.rules > > > diff --git a/arch/x86/um/os-Linux/registers.c > > > b/arch/x86/um/os-Linux/registers.c > > > index eb1cdadc8a61..55bce0d3f5d2 100644 > > > --- a/arch/x86/um/os-Linux/registers.c > > > +++ b/arch/x86/um/os-Linux/registers.c > > > @@ -6,18 +6,20 @@ > > > > > > #include <errno.h> > > > > Given that you are explicitly disabling errno support for nolibc, is > > this include necessary? > > I think it is technically correct as we do need ENODEV and ENOMEM to be > defined. Not that we actually need the include if we pull in nolibc.h.
Yes, indeed. > Considering we would never build against libc, should we maybe just do > an explicit nolibc.h include and rely on it pulling in the rest > automatically? That seems a bit weird to me, but as-is we will never > notice when we forget an include. Your choice. nolibc will always include itself fully transitively in any case. So you won't notice a missing include that way either. The different headers mostly exist to structure the nolibc sources themselves and to let the application code look normal. I would go with normal includes. > > > #include <stdlib.h> > > > -#include <sys/ptrace.h> > > > +#include <linux/ptrace.h> > > > #ifdef __i386__ > > > #include <sys/user.h> > > > #endif > > > #include <longjmp.h> > > > #include <sysdep/ptrace_user.h> > > > -#include <sys/uio.h> > > > +#include <linux/uio.h> > > > > It looks fairly trivial to add sys/uio.h to nolibc. > > Only 'struct iovec' (already provided by the UAPI) and readv()/writev() > > are necessary. > > > > > #include <asm/sigcontext.h> > > > #include <linux/elf.h> > > > #include <registers.h> > > > #include <sys/mman.h> > > > > > > +#define my_ptrace(...) my_syscall4(__NR_ptrace, __VA_ARGS__) > > > > Why not add sys/ptrace.h to nolibc and then use sys_ptrace()? > > Honestly, I just got a bit lazy at that point and this was a reasonable > proof that mixing nolibc with libc works fine. Fair enough :-) > You are absolutely right > that it would be better to add this to nolibc. > > > In general I'm not a fan of the my_syscall() naming scheme and would > > like to change this in nolibc itself, so having fewer external users > > would be nice. > > How about adding a sys_syscall macro? That would match the naming > scheme of the other functions. Then, once all users are ported, one can > simply change the my_ prefix to __nolibc_. sys_syscall() looks weird. Personally I would have gone with _syscall(). Let's just sidestep the issue for now by adding sys_ptrace() to nolibc. (...)
