This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 01/10/2018 12:53 PM, Adhemerval Zanella wrote:
On 10/01/2018 08:21, Florian Weimer wrote:I verified that without the guard accounting change in commit 630f4cc3aa019ede55976ea561f1a7af2f068639 (Fix stack guard size accounting) the tst-minstack-cancel test fails on an AVX-512F machine. (tst-minstack-exit still passes.) The two tests cannot be merged because lazy binding in libgcc occurs only once and contributes significantly to stack usage, so the first test would alter stack usage in the second test. 2018-01-10 Florian Weimer <fweimer@redhat.com> [BZ #22636] * nptl/Makefile (tests): Add tst-minstack-cancel, tst-minstack-exit. * nptl/tst-minstack-cancel.c, nptl/tst-minstack-exit.c: New files.From the discussion about PTHREAD_STACK_MIN [1] I think the consensus is PTHREAD_STACK_MIN does not include enough stack necessary for the cancellation mechanism. Shouldn't we mark 'tst-minstack-cancel.c' as an XFAIL? [1] https://sourceware.org/ml/libc-alpha/2017-12/msg00816.html
I am pretty sure that PTHREAD_STACK_MIN was sufficient for cancellation to work on glibc 2.26 (as released) and earlier, across all architectures. The test case pretty much mirrors what ntpd does during startup, and it's so widely used that people report problems with that pretty quickly. (It's how this was reported originally.)
I think the XSAVE ld.so trampoline simply introduced a regression, and we are putting in changes to fix it (4 KiB of stack added, libgcc_s.so with RTLD_NOW). The new tests try to make sure that it won't happen again.
Thanks, Florian
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |