Currently, the lib/dns/tests/tkey_test unit test is only run when the
linker supports the --wrap option. However, linker support for that
option is only needed for static builds. As a result, the unit test
mentioned before is not being run everywhere it can be run as even for
builds done using --with-libtool, the test is not run unless the linker
supports the --wrap option.
Tweak preprocessor directives in lib/dns/tests/tkey_test.c so that this
test is run:
- for all builds using --with-libtool,
- for static builds done using a linker supporting the --wrap option.
Weak symbols are handled differently by different dynamic linkers. With
glibc, lib/dns/tests/tkey_test works as expected no matter whether
--with-libtool is used or not: __attribute__((weak)) prevents a static
build from failing and it just so happens that the desired symbols are
picked at runtime for dynamic builds. However, with BSD libc, the
libdns functions called from lib/dns/tests/tkey_test.c use the "real"
memory allocation functions from libisc, thus breaking that unit test.
(Note: similar behavior can be reproduced with glibc by setting the
LD_DYNAMIC_WEAK environment variable.)
The simplest way to make lib/dns/tests/tkey_test work reliably is to
drop all uses of __attribute__((weak)) in it - this way, the memory
functions inside lib/dns/tests/tkey_test.c will always be used instead
of the "real" libisc ones for dynamic builds. However, this would not
work with static builds as it would result in multiple strong symbols
with the same name being present in a single binary.
Work around the problem by only compiling in the overriding definitions
of memory functions when building using --with-libtool. For static
builds, keep relying on the --wrap linker option for replacing calls to
the functions we are interested in.
All unit tests define the UNIT_TESTING macro, which causes <cmocka.h> to
replace malloc(), calloc(), realloc(), and free() with its own functions
tracking memory allocations. In order for this not to break
compilation, the system header declaring the prototypes for these
standard functions must be included before <cmocka.h>.
Normally, these prototypes are only present in <stdlib.h>, so we make
sure it is included before <cmocka.h>. However, musl libc also defines
the prototypes for calloc() and free() in <sched.h>, which is included
by <pthread.h>, which is included e.g. by <isc/mutex.h>. Thus, unit
tests including "dnstest.h" (which includes <isc/mem.h>, which includes
<isc/mutex.h>) after <cmocka.h> will not compile with musl libc as for
these programs, <sched.h> will be included after <cmocka.h>.
Always including <cmocka.h> after all other header files is not a
feasible solution as that causes the mock assertion macros defined in
<isc/util.h> to mangle the contents of <cmocka.h>, thus breaking
compilation. We cannot really use the __noreturn__ or analyzer_noreturn
attributes with cmocka assertion functions because they do return if the
tested condition is true. The problem is that what BIND unit tests do
is incompatible with Clang Static Analyzer's assumptions: since we use
cmocka, our custom assertion handlers are present in a shared library
(i.e. it is the cmocka library that checks the assertion condition, not
a macro in unit test code). Redefining cmocka's assertion macros in
<isc/util.h> is an ugly hack to overcome that problem - unfortunately,
this is the only way we can think of to make Clang Static Analyzer
properly process unit test code. Giving up on Clang Static Analyzer
being able to properly process unit test code is not a satisfactory
solution.
Undefining _GNU_SOURCE for unit test code could work around the problem
(musl libc's <sched.h> only defines the prototypes for calloc() and
free() when _GNU_SOURCE is defined), but doing that could introduce
discrepancies for unit tests including entire *.c files, so it is also
not a good solution.
All in all, including <sched.h> before <cmocka.h> for all affected unit
tests seems to be the most benign way of working around this musl libc
quirk. While quite an ugly solution, it achieves our goals here, which
are to keep the benefit of proper static analysis of unit test code and
to fix compilation against musl libc.
When the unit test is linked with dynamic libraries, the wrapping
doesn't occur, probably because it's different translation unit.
To workaround the issue, we provide thin wrappers with *real* symbol
names that just call the mocked functions.
The common construct seen in the BIND 9 source is func(isc_mem_t *mctx, ...).
Unfortunately, the dnstest.{h,c} has been using mctx as a global symbol, which
in turn generated a lot of errors when update.c got included in update_test.c.
As a rule of thumb, we should avoid naming global symbols with generic names
(like mctx) and we should prefix them with "namespace" (like dt_mctx).
