[Buildroot] Analysis of build results for 2021-03-03
Peter Korsgaard
peter at korsgaard.com
Fri Mar 5 08:36:20 UTC 2021
>>>>> "Yann" == Yann E MORIN <yann.morin.1998 at free.fr> writes:
Hi,
>> This is a bug in uClibc: it implements renameat() only if the
>> SYS_renameat system call exists. If only the SYS_renameat2 system call
>> exists, the renameat() function is not implemented. Musl does this
>> correctly:
>>
>> int renameat(int oldfd, const char *old, int newfd, const char *new)
>> {
>> #ifdef SYS_renameat
>> return syscall(SYS_renameat, oldfd, old, newfd, new);
>> #else
>> return syscall(SYS_renameat2, oldfd, old, newfd, new, 0);
>> #endif
>> }
>>
>> uclibc needs to be patched here.
> But what about external toolchains? We can't know whether they would
> carry such a patch or not...
But that is the general issue with external uClibc-based toolchains, we
cannot really do anything about it.
Thomas, will you create a uclibc-ng patch?
>> > aarch64 | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/739d625673f9b2ce2d915ecdc21910c62618d145 |
>> > microblazeel | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/b1779a7d46f6ee9c06864c3ca252f1cdad47cf08 |
>> > i586 | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/a5fe402e3f4e538eb4584f345b029ef12ad43348 |
>> > arc | host-sentry-cli-1.57.0 | NOK | http://autobuild.buildroot.net/results/abd3f886335f146ff6f16370484106bd8a205bda |
>> What do we do with this? The only way to solve that is to have the
>> Cargo vendoring support, which we won't have for 2021.02. Should we
>> drop this package ?
> I am all in favour of dropping sentry-cli. It is a host-only package
> with no in-tree users. When it was submitted, no rationale was given to
> justify for having it upstream (although I suspect it may be helpfull
> with traces generated with sentry-native).
> In any case, this package is not playing nice with our infra, and our
> infra is not ready to accomodate such a package yet.
> Let's drop it for now...
Fine by me.
>> > nios2 | libgeos-3.9.0 | NOK |
>> > http://autobuild.buildroot.net/results/a05fdf1958f93a206c5c66c7f636b6650683626d
>> > | ORPH
>> Some more nios2 toolchain issue.
>> Should we get rid of nios2 support entirely ?
> How prevalent is nios2? What's the support in the kernel? Some time ago,
> quite a few old architectures were dropped; IIR, a few others were put
> on trial to see if they were really still alive (but apart an LWN
> article https://lwn.net/Articles/748074/ I can't find that list...)
There is also https://lwn.net/Articles/838807/, which doesn't even list
nios2. I believe it was added back in 2014:
https://lwn.net/Articles/619011/
I think running Linux on nios2 is fairly rare, but there are users. As a
data point, it looks like the clone syscall got broken almost a year
ago, and has recently been fixed by someone from Siemens:
commit 9abcfcb20320e8f693e89d86573b58e6289931cb
Author: Andreas Oetken <andreas.oetken at siemens.com>
Date: Fri Feb 19 14:41:03 2021 +0800
nios2: fixed broken sys_clone syscall
The tls pointer must be pushed on the stack prior to calling nios2_clone
as it is the 5th function argument. Prior handling of the tls pointer was
done inside former called function copy_thread_tls using the r8 register
from the current_pt_regs directly. This was a bad design and resulted in
the current bug introduced in 04bd52fb.
Fixes: 04bd52fb ("nios2: enable HAVE_COPY_THREAD_TLS, switch to kernel_clone_args")
Signed-off-by: Andreas Oetken <andreas.oetken at siemens.com>
Signed-off-by: Ley Foon Tan <ley.foon.tan at intel.com>
Acked-by: Christian Brauner <christian.brauner at ubuntu.com>
Looking at the history of arch/nios2, almost all recent changes looks to
be from non-nios2 developers doing kernel wide changes, so I would say
it is fairly dead, E.G. the last functional code change authored by
someone from Intel is from 2018:
commit cb9f753a3731f7fe16447bea45cb6f8e8bb432fb
Author: Huang Ying <ying.huang at intel.com>
Date: Thu Apr 5 16:24:39 2018 -0700
mm: fix races between swapoff and flush dcache
So I don't have an issue with us getting rid of nios2 post-2021.02. I'll
try to remember to add a note about it in the announcement mail, so if
there are active users they will hopefully speak up.
>> > arm | toolchain-external-linaro-a... | NOK |
>> > http://autobuild.buildroot.net/results/d9b9a4b7c3660bd730a19ab09e44f24bc29e3f40
>> > | ORPH
>> > arm | toolchain-external-linaro-a... | NOK |
>> > http://autobuild.buildroot.net/results/13f9a551f5ac911e7daa2a382b0683d81486cffa
>> > | ORPH
>> toolchain is gone ?
> I can get it from here;
Yes, I already pushed it to s.b.o yesterday afternoon when I noticed the
failure.
--
Bye, Peter Korsgaard
More information about the buildroot
mailing list