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(a)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(a)uclibc-ng.org
> To unsubscribe send an email to devel-leave(a)uclibc-ng.org
>