[RFC 1/2] tools/nolibc: add sigaction()

[Berg, Benjamin]

Hi,

On Fri, 2025-06-27 at 09:45 +0200, Thomas Weißschuh wrote:
> On Fri, Jun 27, 2025 at 06:46:56AM +0000, Berg, Benjamin wrote:
> > [SNIP]
> > 
> > Oh, is there a convenient way to cross-compile for various
> > architectures and run them using qemu?
> > 
> > So far I only tried x86/x86_64.
> 
> We have a script for that in the nolibc testsuite:
> 
> $ cd tools/testing/selftests/nolibc/
> $ ./run-tests.sh -p -m user
> i386:          225 test(s): 222 passed,   3 skipped,   0 failed => status: warning
> x86_64:        225 test(s): 222 passed,   3 skipped,   0 failed => status: warning
> arm64:         225 test(s): 222 passed,   3 skipped,   0 failed => status: warning
> ...
> 
> "-p" downloads a bunch of toolchains from kernel.org
> "-m user" uses qemu-user. "-m system", or no "-m" at all would build a kernel and use qemu-system.
> "-l" will use llvm/clang instead of gcc (only use with "-m user").
> 
> Actual tests are in nolibc-test.c.

Neat! Need to try that some time, this isn't high priority for me
though.

> > > [SNIP]
> > 
> > Maybe we should just set it in the CFLAGS directly then?
> 
> We also don't control the CFLAGS the user is using.
> 
> > Honestly, I am not entirely sure how you are supposed to do it
> > correctly. The thing is, if I do not set __KERNEL__, then I get the old
> > compatibility defines and types from asm/signal.h.
> > 
> > And, I do not see an alternative way. It would not be safe to avoid the
> > include entirely and if you try that you are also missing the
> > SA_RESTORER define for the proper "struct sigaction" definition to be
> > correct.
> > 
> > The best alternative I see would be copying the proper definitions into
> > the architecture specific header. That would also be ugly, as one would
> > need to do a "struct sigaction" -> "struct nolibc_rt_sigaction"
> > conversion internally. But, that would have the advantage that nolibc
> > works outside of the kernel tree.
> 
> I think we need to do something like this.
> Luckily the real mess seems to be only on x86.

Right, if it is just x86, then it isn't too bad. "Just" needs some
header magic so that it doesn't get into the way of the user too much.

> > Even if all this is ugly, I would prefer that over using the
> > compatibility sigaction syscall instead of rt_sigaction.
> 
> As an alternative, you are not forced to use nolibc for the KUnit UAPI
> framework. You can depend on CONFIG_CC_CAN_LINK_STATIC=y and use "-static" for
> the toolchains "real" libc.
> Not that I want to discourage you from contributing to nolibc, though.

Oh, I absolutely do not want to use glibc :-)

The thing is, I *really* want to use nolibc for the UM kernel itself
and drop glibc support entirely as glibc is a huge mess. For example,
the um kernel tries to override the malloc function to map it to
kmalloc after initialization. But then, that does not even work, and
glibc itself continues to use its own implementation … this kind of
stuff seems like a recipe for disaster.

Now, I don't mind doing raw syscalls in the um kernel. But basic signal
handling seems like a nice addition for nolibc.

Benjamin

> 
> > > > +
> > > >  #include "std.h"
> > > >  #include "arch.h"
> > > >  #include "types.h"
> > > > diff --git a/tools/include/nolibc/signal.h b/tools/include/nolibc/signal.h
> > > > index ac13e53ac31d..fa52119e577f 100644
> > > > --- a/tools/include/nolibc/signal.h
> > > > +++ b/tools/include/nolibc/signal.h
> > > > @@ -14,6 +14,7 @@
> > > >  #include "arch.h"
> > > >  #include "types.h"
> > > >  #include "sys.h"
> > > > +#include <linux/signal.h>
> > > >  
> > > >  /* This one is not marked static as it's needed by libgcc for divide by zero */
> > > >  int raise(int signal);
> > > > @@ -23,4 +24,37 @@ int raise(int signal)
> > > >  	return sys_kill(sys_getpid(), signal);
> > > >  }
> > > >  
> > > > +/*
> > > > + * sigaction(int signum, const struct sigaction *act, struct sigaction *oldact)
> > > > + */
> > > > +
> > > > +#ifdef SA_RESTORER
> > > > +__attribute__((naked))
> > > 
> > > __attribute__((naked)) is not supported everywhere.
> > 
> > One can just drop it. It just felt it was cleaner as we really just
> > want to set the register and do the syscall without modifying the
> > stack.
> 
> If it works without, also good.
> If you want you can also use __nolibc_has_attribute(naked) from compiler.h.
> 
> <snip>

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Sean Fennelly, Jeffrey Schneiderman, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928