Hi Max, Max Filippov wrote, > Hi Waldemar, > > On Mon, May 6, 2024 at 11:17 AM Max Filippov <jcmvb...@gmail.com> wrote: > > On Sun, May 5, 2024 at 2:51 AM Waldemar Brodkorb <w...@openadk.org> wrote: > > > > On Sat, May 4, 2024 at 12:14 AM Max Filippov <jcmvb...@gmail.com> wrote: > > > > also the following tests either hang or cause problems, > > > > so I disabled them as well: > > > > > > > > mmap/mmap2 \ > > > > nptl/tst-basic7 \ > > > > nptl/tst-cond3 \ > > > > nptl/tst-eintr1 \ > > > > nptl/tst-eintr2 \ > > > > nptl/tst-eintr3 \ > > > > nptl/tst-eintr4 \ > > > > nptl/tst-eintr5 \ > > > > nptl/tst-exit2 \ > > > > nptl/tst-exit3 \ > > > > nptl/tst-mqueue6 \ > > > > nptl/tst-stdio1 > > > > > > I would like to disable these tests only for Xtensa FDPIC > > > > I doubt that they're FDPIC-specific. The mmap2 is clearly related to > > noMMU, I haven't looked closely at the rest yet, I'll do it this week. > > Most of the issues with the tests in the above list are caused by > using direct ( -d ) mode to run them when targeting noMMU, > but it seems to me that it doesn't have to be like that: even on > noMMU the test skeleton can do vfork and exec itself in direct > mode. I'll post a patch that implements this change, with that > patch most of the above tests run to successful completion. > > There's still a few failures I observe with the xtensa FDPIC port > even with that change: > > nptl/tst-attr3 -- fails because thread stack guard size in the test is > the same as the default thread stack size. Building uclibc with > bigger default stack size fixes that failure. > > nptl/tst-basic7 -- fails because it sets prlimit(RLIMIT_AS) to 10MB > and tries to exhaust it, but mmap doesn't fail on noMMU until > it runs out of memory. It looks like a kernel bug to me (there's > no call to may_expand_vm() from the nommu do_mmap version). > If it's supposed to be like that on the kernel side it means that this > test is not applicable on a noMMU target. > > nptl/tst-cancel7, nptl/tst-cancelx7 -- fail because it expects that a > shell started by system() execs the program without forking, so > that killing it releases the file lock it might have taken. It seems > to me that it relies on implementation details (not even the libc > implementation details) and the test should be fixed. > > nptl/tst-mqueue6 -- fails because mq_notify() called with > notification->sigev_notify set to SIGEV_THREAD fails with > ENOSYS, because init_mq_netlink() calls pthread_atfork(), > which is not implemented on noMMU. It seems to me that either > pthread_atfork may be avoided on a noMMU target, or it can be > implemented on a noMMU target. Or the test is not applicable > on a noMMU target. > > unistd/errno -- fails because of the stupid mistake in the xtensa > FDPICI port I introduced at a recent code rebase (missing ';' > after FDPIC_LOAD_JUMPTARGET in the > SYSCALL_ERROR_HANDLER variant for linuxthreads, that > swallowed the following call to __errno_location()) and that > surprisingly wasn't caught by the assembler. I fixed it by adding > the ';' and also defining USE___THREAD in ASFLAGS in the > xtensa NPTL port, so that the appropriate version of > SYSCALL_ERROR_HANDLER is used for linuxthreads and > for NPTL.
Thanks for the explanations. Is the uClibc-ng port ready to commit or do you have any changes open? best regards Waldemar _______________________________________________ devel mailing list -- devel@uclibc-ng.org To unsubscribe send an email to devel-le...@uclibc-ng.org
