Hi Waldemar,

Hi Ben,

can you explain what this patch is fixing exactly? Is it a runtime or compile time bug going away with this patch?

The bug is that on no-MMU ARM with stubs enabled, there is no fork() stub (and of course no real implementation of fork()).

I thought fork() is not supported, but clone() is.

Yes, you are right. What I should have said is that clone() cannot be used to implement fork() on no-MMU. That does perhaps imply that the correct way to fix this bug is to add !__ARCH_USE_MMU__ to the condition that enables the fork() stub, rather than undefining __NR_clone.

Thanks, Ben

Ben Wolsieffer wrote,

...

From: Ben Wolsieffer Ben.Wolsieffer@hefring.com

The stub code undefs __NR_fork on no-MMU systems, but it also needs to undef __NR_clone since fork can now be implemented using clone, and clone is not available either on no-MMU systems.

---

libc/sysdeps/linux/common/stubs.c | 1 + 1 file changed, 1 insertion(+)

diff --git a/libc/sysdeps/linux/common/stubs.c b/libc/sysdeps/linux/common/stubs.c index c17e509b9..11849e3ba 100644 --- a/libc/sysdeps/linux/common/stubs.c +++ b/libc/sysdeps/linux/common/stubs.c @@ -36,6 +36,7 @@ __attribute_used__ static int ret_enosys_stub(void)

#ifndef __ARCH_USE_MMU__ # undef __NR_fork +# undef __NR_clone #endif

#ifdef __arm__

2.42.0

---

devel mailing list -- devel@uclibc-ng.org To unsubscribe send an email to devel-leave@uclibc-ng.org