On 2025-07-04 15:33:09+0200, Willy Tarreau wrote:
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'm all for keeping it simple. However here I think we disagree about the aproach which would be simpler. As mentioned before let's go with Benjamin's and I'll try to do my thing on top. Then we can actually compare two working aproaches (if my idea does work).
<snip>