Hello,
I've noticed that with the uclibc-ng 1.0.39 the tests tst-cancel18 and tst-cancelx18 are failing in NPTL-enabled configs (on xtensa). Bisection pointed me to the commit 08d46f1ce21e ("librt: avoid compilation error") which effectively turned off cancellation for clock_nanosleep.
Reverting it fixes the tests for me, and does not break uclibc-ng build on nommu configs with or without threads support.
So I'm curious what was the original issue that mentioned commit tried to solve (what arch/config)?
On Tue, 2022-03-08 at 19:15 -0800, Max Filippov wrote:
Hello,
I've noticed that with the uclibc-ng 1.0.39 the tests tst-cancel18 and tst-cancelx18 are failing in NPTL-enabled configs (on xtensa). Bisection pointed me to the commit 08d46f1ce21e ("librt: avoid compilation error") which effectively turned off cancellation for clock_nanosleep.
Reverting it fixes the tests for me, and does not break uclibc-ng build on nommu configs with or without threads support.
So I'm curious what was the original issue that mentioned commit tried to solve (what arch/config)?
Compilation errors with riscv arch. The commit message describe the problem. The fix though is clearly not perfect since it causes problems for you on xtensa.
Hi, Damien Le Moal wrote,
On Tue, 2022-03-08 at 19:15 -0800, Max Filippov wrote:
Hello,
I've noticed that with the uclibc-ng 1.0.39 the tests tst-cancel18 and tst-cancelx18 are failing in NPTL-enabled configs (on xtensa). Bisection pointed me to the commit 08d46f1ce21e ("librt: avoid compilation error") which effectively turned off cancellation for clock_nanosleep.
Reverting it fixes the tests for me, and does not break uclibc-ng build on nommu configs with or without threads support.
So I'm curious what was the original issue that mentioned commit tried to solve (what arch/config)?
Compilation errors with riscv arch. The commit message describe the problem. The fix though is clearly not perfect since it causes problems for you on xtensa.
I tested now with the patch reverted and the compile succeeded. There is indeed a warning thrown by gcc. Have you set -Werror to your compiler cflags? Or can you sent your uclibc-ng.config to see what is triggering the error?
BTW: When do you sent the new buildroot series? I was trying to compile a system for sipeed-maixbit in OpenADK, but hush is always segfaulting for me. I want to identify the differences to buldroot.
best regards Waldemar
On Wed, Mar 9, 2022 at 6:33 AM Waldemar Brodkorb wbx@uclibc-ng.org wrote:
Compilation errors with riscv arch.
I tested now with the patch reverted and the compile succeeded. There is indeed a warning thrown by gcc.
The following warnings?
librt/clock_nanosleep.c: In function 'clock_nanosleep': librt/clock_nanosleep.c:43:22: warning: implicit declaration of function 'LIBC_CANCEL_ASYNC'; did you mean 'LIBC_CANCEL_HANDLED'? [-Wimplicit-function-declaration] int oldstate = LIBC_CANCEL_ASYNC (); ^~~~~~~~~~~~~~~~~ LIBC_CANCEL_HANDLED librt/clock_nanosleep.c:48:7: warning: implicit declaration of function 'LIBC_CANCEL_RESET'; did you mean 'LIBC_CANCEL_HANDLED'? [-Wimplicit-function-declaration] LIBC_CANCEL_RESET (oldstate); ^~~~~~~~~~~~~~~~~ LIBC_CANCEL_HANDLED
They definitely mean that building a riscv program that calls clock_nanosleep will fail with references to undefined symbols, so just reverting that patch doesn't look like a solution. Maybe there's a way to make riscv port more like other ports that support both mmu+NPTL and nommu, I'm looking into it.
On Wed, 2022-03-09 at 12:51 -0800, Max Filippov wrote:
On Wed, Mar 9, 2022 at 6:33 AM Waldemar Brodkorb wbx@uclibc-ng.org wrote:
Compilation errors with riscv arch.
I tested now with the patch reverted and the compile succeeded. There is indeed a warning thrown by gcc.
The following warnings?
Yes, it was something like that.
librt/clock_nanosleep.c: In function 'clock_nanosleep': librt/clock_nanosleep.c:43:22: warning: implicit declaration of function 'LIBC_CANCEL_ASYNC'; did you mean 'LIBC_CANCEL_HANDLED'? [-Wimplicit-function-declaration] int oldstate = LIBC_CANCEL_ASYNC (); ^~~~~~~~~~~~~~~~~ LIBC_CANCEL_HANDLED librt/clock_nanosleep.c:48:7: warning: implicit declaration of function 'LIBC_CANCEL_RESET'; did you mean 'LIBC_CANCEL_HANDLED'? [-Wimplicit-function-declaration] LIBC_CANCEL_RESET (oldstate); ^~~~~~~~~~~~~~~~~ LIBC_CANCEL_HANDLED
They definitely mean that building a riscv program that calls clock_nanosleep will fail with references to undefined symbols, so just reverting that patch doesn't look like a solution. Maybe there's a way to make riscv port more like other ports that support both mmu+NPTL and nommu, I'm looking into it.
Sounds good. Thanks for that.
On Wed, 2022-03-09 at 15:33 +0100, Waldemar Brodkorb wrote:
Hi, Damien Le Moal wrote,
On Tue, 2022-03-08 at 19:15 -0800, Max Filippov wrote:
Hello,
I've noticed that with the uclibc-ng 1.0.39 the tests tst-cancel18 and tst-cancelx18 are failing in NPTL-enabled configs (on xtensa). Bisection pointed me to the commit 08d46f1ce21e ("librt: avoid compilation error") which effectively turned off cancellation for clock_nanosleep.
Reverting it fixes the tests for me, and does not break uclibc-ng build on nommu configs with or without threads support.
So I'm curious what was the original issue that mentioned commit tried to solve (what arch/config)?
Compilation errors with riscv arch. The commit message describe the problem. The fix though is clearly not perfect since it causes problems for you on xtensa.
I tested now with the patch reverted and the compile succeeded. There is indeed a warning thrown by gcc. Have you set -Werror to your compiler cflags? Or can you sent your uclibc-ng.config to see what is triggering the error?
I do not remember exactly. It might have been warnings only, but I personally consider warnings as compile errors :)
BTW: When do you sent the new buildroot series? I was trying to compile a system for sipeed-maixbit in OpenADK, but hush is always segfaulting for me. I want to identify the differences to buldroot.
Still working on it. Niklas in my team has finally figured out all the problems we were seeing with SD card and reset (caused by various issues in u-boot, DTS and SPI flash). We now have something solid for u-boot and the kernel, booting either with or without uboot. All patches have been sent upstream and should land in 5.17 for the kernel and u-boot tree.
Userspace though is still fragile. My latest k210-v12 branch used to work fine and booting up to a functional shell, but rebasing it on latest buildroot causes 100% crashes of hush on startup (segfault). I suspect that there is still something missing in elf2flt support. Niklas is looking into it.
best regards Waldemar
-
Damien Le Moal -
Max Filippov -
Waldemar Brodkorb