Re: [RFC v2] tools/nolibc: add sigaction()

[Willy Tarreau <w@1wt.eu>]

On Fri, Jul 04, 2025 at 12:50:32PM +0200, Thomas Weißschuh wrote:
> On 2025-07-02 17:33:24+0200, Benjamin Berg wrote:
> > On Wed, 2025-07-02 at 00:04 +0200, Thomas Weißschuh wrote:
> > > [SNIP]
> > > > --- a/tools/include/nolibc/arch-i386.h
> > > > +++ b/tools/include/nolibc/arch-i386.h
> > > > @@ -10,6 +10,19 @@
> > > >  #include "compiler.h"
> > > >  #include "crt.h"
> > > >  
> > > > +/* Needed to get the correct struct sigaction definition */
> > > > +#define SA_RESTORER	0x04000000
> > > > +
> > > > +/* Restorer must be set on i386 */
> > > > +#define _NOLIBC_ARCH_NEEDS_SA_RESTORER
> > > > +
> > > > +/* Otherwise we would need to use sigreturn instead of rt_sigreturn */
> > > > +#define _NOLIBC_ARCH_FORCE_SIG_FLAGS SA_SIGINFO
> > > > +
> > > > +/* Avoid linux/signal.h, it has an incorrect _NSIG and sigset_t */
> > > > +#include <asm-generic/signal.h>
> > > > +#include <asm-generic/siginfo.h>
> > > 
> > > This doesn't work if the user already has <linux/signal.h> included for
> > > some other reason. The symbol names will conflict.
> > 
> > I was thinking this is fine. Such a conflict already exists between the
> > normal glibc <signal.h> and <linux/signal.h>.
> 
> It would be enough to keep compatibility with glibc.
> But personally I'd like to make it work generally.
> 
> > So there would only be a
> > problem if the user is explicitly not including <signal.h> to then use
> > <linux/signal.h>. I doubt that makes sense.
> 
> Technically nolibc is always included as a whole, so any application
> using it would be prevented from using linux/signal.h.
> 
> Maybe Willy has some strong opinions.
> Otherwise I'm also fine if we keep this part as is for now.
> Then if everything else is addressed I'll try to actually implement my
> proposal on top.
> 
> Does this sound reasonable?

I think that userland application writers are used to seeing random
failures here and there when they start using linux/ without being invited
to do so. Of course it's never fun to deal with build failures, but the
effort spent overengineering solutions is often not worth being spent
when you figure that sometimes the next application you try will blatantly
fail again. I'd suggest that we stay on the pragmatic side of things: if
we find a solution that works fine for the common case, that may break for
rare cases that already break with glibc, I think we're already fine. That
doesn't mean we don't need to think about it, but it's not something urgent
nor that warrants taking more risks either.

I personally also think that we'll face an increasing amount of build
issue reports due to our attempt at being more compatible. Indeed, in the
past, one had to #ifdef all includes and pass -include nolibc on the gcc
command line. Nowadays by supporting a larger number of functions and
include file names, we encourage developers to try to simply switch their
libc for nolibc. We do know that the coverage remains low, and reports
will come proportionally to the ratio of apparent ease of use to feature
coverage. That's expected and we should try to resist feeling bad about
it. I don't think we'll ever aim at competing with glibc/musl for example,
so a little bit of application adaptation is expected from time to time.

Cheers,
Willy