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

["Thomas Weißschuh" <linux@weissschuh.net>]

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?


Thomas