opnsense-src/lib/libc/tests/stdlib/Makefile

65 lines
1.6 KiB
Makefile
Raw Normal View History

# $FreeBSD$
Add __cxa_thread_atexit(3) API implementation. This is the backing feature to implement C++11 thread storage duration specified by the thread_local keyword. A destructor for given thread-local object is registered to be executed at the thread termination time using __cxa_thread_atexit(). Libc calls the __cxa_thread_calls_dtors() during exit(3), before finalizers and atexit functions, and libthr calls the function at the thread termination time, after the stack unwinding and thread-specific key destruction. There are several uncertainties in the API which lacks a formal specification. Among them: - is it allowed to register destructors during destructing; we allow, but limiting the nesting level. If too many iterations detected, a diagnostic is issued to stderr and thread forcibly terminates for now. - how to handle destructors which belong to an unloading dso; for now, we ignore destructor calls for such entries, and issue a diagnostic. Linux does prevent dso unload until all threads with destructors from the dso terminated. It is supposed that the diagnostics allow to detect real-world applications relying on the above details and possibly adjust our implementation. Right now the choices were to provide the slim API (but that rarely stands the practice test). Tests are added to check generic functionality and to specify some of the above implementation choices. Submitted by: Mahdi Mokhtari <mokhi64_gmail.com> Reviewed by: theraven Discussed with: dim (detection of -std=c++11 supoort for tests) Sponsored by: The FreeBSD Foundation (my involvement) MFC after: 2 weeks Differential revisions: https://reviews.freebsd.org/D7224, https://reviews.freebsd.org/D7427
2016-08-06 09:32:40 -04:00
.include <src.opts.mk>
ATF_TESTS_C+= heapsort_test
ATF_TESTS_C+= mergesort_test
ATF_TESTS_C+= qsort_test
ATF_TESTS_C+= set_constraint_handler_s_test
Let tsearch()/tdelete() use an AVL tree. The existing implementations of POSIX tsearch() and tdelete() don't attempt to perform any balancing at all. Testing reveals that inserting 100k nodes into a tree sequentially takes approximately one minute on my system. Though most other BSDs also don't use any balanced tree internally, C libraries like glibc and musl do provide better implementations. glibc uses a red-black tree and musl uses an AVL tree. Red-black trees have the advantage over AVL trees that they only require O(1) rotations after insertion and deletion, but have the disadvantage that the tree has a maximum depth of 2*log2(n) instead of 1.44*log2(n). My take is that it's better to focus on having a lower maximum depth, for the reason that in the case of tsearch() the invocation of the comparator likely dominates the running time. This change replaces the tsearch() and tdelete() functions by versions that create an AVL tree. Compared to musl's implementation, this version is different in two different ways: - We don't keep track of heights; just balances. This is sufficient. This has the advantage that it reduces the number of nodes that are being accessed. Storing heights requires us to also access all of the siblings along the path. - Don't use any recursion at all. We know that the tree cannot 2^64 elements in size, so the height of the tree can never be larger than 96. Use a 128-bit bitmask to keep track of the path that is computed. This allows us to iterate over the same path twice, meaning we can apply rotations from top to bottom. Inserting 100k nodes into a tree now only takes 0.015 seconds. Insertion seems to be twice as fast as glibc, whereas deletion has about the same performance. Unlike glibc, it uses a fixed amount of memory. I also experimented with both recursive and iterative bottom-up implementations of the same algorithm. This iterative top-down version performs similar to the recursive bottom-up version in terms of speed and code size. For some reason, the iterative bottom-up algorithm was actually 30% faster for deletion, but has a quadratic memory complexity to keep track of all the parent pointers. Reviewed by: jilles Obtained from: https://github.com/NuxiNL/cloudlibc Differential Revision: https://reviews.freebsd.org/D4412
2015-12-22 13:12:11 -05:00
ATF_TESTS_C+= tsearch_test
Add __cxa_thread_atexit(3) API implementation. This is the backing feature to implement C++11 thread storage duration specified by the thread_local keyword. A destructor for given thread-local object is registered to be executed at the thread termination time using __cxa_thread_atexit(). Libc calls the __cxa_thread_calls_dtors() during exit(3), before finalizers and atexit functions, and libthr calls the function at the thread termination time, after the stack unwinding and thread-specific key destruction. There are several uncertainties in the API which lacks a formal specification. Among them: - is it allowed to register destructors during destructing; we allow, but limiting the nesting level. If too many iterations detected, a diagnostic is issued to stderr and thread forcibly terminates for now. - how to handle destructors which belong to an unloading dso; for now, we ignore destructor calls for such entries, and issue a diagnostic. Linux does prevent dso unload until all threads with destructors from the dso terminated. It is supposed that the diagnostics allow to detect real-world applications relying on the above details and possibly adjust our implementation. Right now the choices were to provide the slim API (but that rarely stands the practice test). Tests are added to check generic functionality and to specify some of the above implementation choices. Submitted by: Mahdi Mokhtari <mokhi64_gmail.com> Reviewed by: theraven Discussed with: dim (detection of -std=c++11 supoort for tests) Sponsored by: The FreeBSD Foundation (my involvement) MFC after: 2 weeks Differential revisions: https://reviews.freebsd.org/D7224, https://reviews.freebsd.org/D7427
2016-08-06 09:32:40 -04:00
.if ${COMPILER_FEATURES:Mc++11}
ATF_TESTS_CXX+= cxa_thread_atexit_test
ATF_TESTS_CXX+= cxa_thread_atexit_nothr_test
.endif
# Not sure why this isn't defined for all architectures, since most
# have long double.
.if ${MACHINE_CPUARCH} == "aarch64" || \
${MACHINE_CPUARCH} == "amd64" || \
${MACHINE_CPUARCH} == "i386"
CFLAGS+= -D__HAVE_LONG_DOUBLE
.endif
# TODO: t_getenv_thread, t_mi_vector_hash, t_strtoi
NETBSD_ATF_TESTS_C+= abs_test
NETBSD_ATF_TESTS_C+= atoi_test
NETBSD_ATF_TESTS_C+= div_test
NETBSD_ATF_TESTS_C+= getenv_test
NETBSD_ATF_TESTS_C+= exit_test
NETBSD_ATF_TESTS_C+= hsearch_test
NETBSD_ATF_TESTS_C+= posix_memalign_test
NETBSD_ATF_TESTS_C+= random_test
NETBSD_ATF_TESTS_C+= strtod_test
NETBSD_ATF_TESTS_C+= strtol_test
NETBSD_ATF_TESTS_C+= system_test
# TODO: need to come up with a correct explanation of what the patch pho does
# with h_atexit
#ATF_TESTS_SH= atexit_test
NETBSD_ATF_TESTS_SH= getopt_test
.include "../Makefile.netbsd-tests"
BINDIR= ${TESTSDIR}
# TODO: see comment above
#PROGS+= h_atexit
PROGS+= h_getopt h_getopt_long
CFLAGS+= -I${.CURDIR}
Add __cxa_thread_atexit(3) API implementation. This is the backing feature to implement C++11 thread storage duration specified by the thread_local keyword. A destructor for given thread-local object is registered to be executed at the thread termination time using __cxa_thread_atexit(). Libc calls the __cxa_thread_calls_dtors() during exit(3), before finalizers and atexit functions, and libthr calls the function at the thread termination time, after the stack unwinding and thread-specific key destruction. There are several uncertainties in the API which lacks a formal specification. Among them: - is it allowed to register destructors during destructing; we allow, but limiting the nesting level. If too many iterations detected, a diagnostic is issued to stderr and thread forcibly terminates for now. - how to handle destructors which belong to an unloading dso; for now, we ignore destructor calls for such entries, and issue a diagnostic. Linux does prevent dso unload until all threads with destructors from the dso terminated. It is supposed that the diagnostics allow to detect real-world applications relying on the above details and possibly adjust our implementation. Right now the choices were to provide the slim API (but that rarely stands the practice test). Tests are added to check generic functionality and to specify some of the above implementation choices. Submitted by: Mahdi Mokhtari <mokhi64_gmail.com> Reviewed by: theraven Discussed with: dim (detection of -std=c++11 supoort for tests) Sponsored by: The FreeBSD Foundation (my involvement) MFC after: 2 weeks Differential revisions: https://reviews.freebsd.org/D7224, https://reviews.freebsd.org/D7427
2016-08-06 09:32:40 -04:00
CXXFLAGS.cxa_thread_atexit_test+= -std=c++11
CXXFLAGS.cxa_thread_atexit_nothr_test+= -std=c++11
LIBADD.cxa_thread_atexit_test+= pthread
.for t in h_getopt h_getopt_long
CFLAGS.$t+= -I${LIBNETBSD_SRCDIR} -I${SRCTOP}/contrib/netbsd-tests
LDFLAGS.$t+= -L${LIBNETBSD_OBJDIR}
LIBADD.${t}+= netbsd util
.endfor
LIBADD.strtod_test+= m
.include <bsd.test.mk>