[PATCH v3 00/13] GLIBC LoongArch PATCHES
Adhemerval Zanella
adhemerval.zanella@linaro.org
Wed May 11 13:17:10 GMT 2022
On 11/05/2022 03:57, Arnd Bergmann wrote:
> On Tue, May 10, 2022 at 9:37 PM Florian Weimer via Libc-alpha
> <libc-alpha@sourceware.org> wrote:
>>
>>> GCC and Binutils Loongarch parts have been into GNU Open Source community.
>>> Loongarch kernal may be no problem on 5.19:
>>
>> It seems that the Linux 5.19 release date could be really close to the
>> glibc 2.36 release date, or even after it. I think we wouldn't want to
>> release with an ABI whose kernel interface is not in a mainline kernel
>> yet.
>>
>> We have the option to backdate ABIs, so we could release the port with a
>> GLIBC_2.36 ABI baseline in glibc 2.37.
>>
>> Or we could merge the port now, and back it out once more if Linux 5.19
>> does not get released in time.
>>
>> Maybe it's sufficient if the Linux port makes it to mainline during the
>> 5.19 rc phase?
>>
>> Thoughts?
>
> From the kernel side, there is only one open question on the ABI:
> either this will include both clone() and clone3(), or just clone3().
>
> This is a surprisingly hard decision. Normally the policy in the kernel
> is that new architectures only get the latest syscall interface, dropping
> earlier syscalls in favor of backward-compatible new interfaces.
>
> For clone3(), this may not work out because
> - clone3 requires knowing the stack frame size for the child, but
> when emulating clone() in libc, that information may not be there.
> We need to work around this by allowing clone3 to be called without
> a size argument
The clone is used internally without a stack only for fork
(sysdeps/unix/sysv/linux/arch-fork.h) and loongarch seems to be using
__ASSUME_CLONE_DEFAULT and exporting __NR_clone as a distinct syscall
(220).
> - some other architectures still don't implement clone3() since we
> are missing the assembly bits for it. So unlike the other recently
> added calls, there is no minimum kernel version that guarantees clone3
> to be available.
If I understood correctly, Intel has added clone3 support on glibc mainly
to implement full CET (since it required stack size). As far as I know
there is no pressing requirement to use clone3 internally, neither to
export as we did for clone; besides to support an new ABI that only
defines clone3.
> - the seccomp/bfp infrastructure in the kernel cannot currently
> introspect indirect syscall arguments. This has to be added at
> some point anyway, but until then the chrome sandbox disallows
> the clone3 syscall.
>
> The easy way out of course is to include both in the kernel, though
> this feels like taking a step backwards. If libc developers feel strongly
> either way, please also reply on the kernel thread so we can come
> to a consensus more quickly.
I think if kernel allows fork like call for clone3, where if no starting
function is set there is no need for stack or stack size; we can adapt
internally fork to use __clone_internal (which first try to use clone3
and then fallbacks to clone).
Even for x86_64 and i686, clone3 is not used for fork (only for
pthread_create and posix_spawn).
>
> There is still another open discussion that blocks merging the
> loongarch kernel port, but that is only for the bootloader and not
> visible to libc. We should merge it as soon as we have concluded
> both points, but it's unclear if that happens before the merge
> window.
>
> Arnd
More information about the Libc-alpha
mailing list