This is the mail archive of the libc-help@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] |
This is my current 'make check' result. XPASS: elf/tst-protected1a XPASS: elf/tst-protected1b FAIL: malloc/tst-malloc-thread-fail UNSUPPORTED: math/test-nearbyint-except-2 FAIL: nptl/tst-cancel24-static FAIL: posix/tst-getaddrinfo5 Summary of test results: 3 FAIL 2432 PASS 1 UNSUPPORTED 43 XFAIL 2 XPASS malloc/tst-malloc-thread-fail.out says "Timed out: killed the child process". Is it possible that this test failure relates to something with my test environment, rather than my implementation? I'm testing on an ODROID-XU4 board. nptl/tst-cancel24-static.out says "Didn't expect signal from child: got `Segmentation fault'" and this failure is mentioned at <https://sourceware.org/glibc/wiki/Release/2.24#Build_and_test_issues>. (I'm running the test case on the 2.24 version branch). posix/tst-getaddrinfo5 seems to fail because my test board does not have an internet connection. Is it okay to ignore tests listed as UNSUPPORTED, XFAIL, and XPASS? 2016-11-18 3:52 GMT+09:00 Adhemerval Zanella <adhemerval.zanella@linaro.org>: > > > On 17/11/2016 16:27, Nam-goo Lee wrote: >> Hi. >> >> I'm working on an optimized version of strnlen function for arm. >> But following tests fail, and I'm stuck here finding the reasons for >> the failure. >> >> FAIL: string/stratcliff >> FAIL: string/test-stpncpy >> FAIL: string/test-strncpy >> Summary of test results: >> 3 FAIL >> 57 PASS >> >> I'm surprised to see that tests for functions other than strnlen fail. >> I'd really appreciate to get some hints on what the 'stratcliff' test does, >> and the reasons for the failure. >> Attached my code. >> >> Thanks. >> > > Hi, > > ARM uses default string/str{n,p}cpy.c code and strncpy code has: > > 26 char * > 27 STRNCPY (char *s1, const char *s2, size_t n) > 28 { > 29 size_t size = __strnlen (s2, n); > > So if your optimized strnlen does not provide the expected correct result > the code will potentially fail. It might the case where it is stressing > a case that test-strnlen does not issue. Either way, you need to a full > clean make check to make sure the implementation is ready for upstream review.
Attachment:
strnlen.S
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |