Now that the previous commit provides a foundation for what exactly can
go wrong with ld.bfd = 2.29+ linker, let's start reconciling that with
some reasonable assurance that logging is not silently severed, because
realizing the logs are missing is otherwise bound to happen when the
logs are suddently pretty crucial analytical resource :-)
We'll proceed in two steps as detailed.
* * *
As a first step, the table below concludes how the test matrix overview
introduced with a message for the preceding commit (also introducing
log_test_mock.sh runner which got reused here) looks as of this
refreshed sanity check, once QB_LOG_INIT_DATA macro at hand gets applied
(meaning "for non-libqb logging participants" so as not complicate the
matrix further). That macro is nothing triggered directly, it will just
plant a constructor-like function (to be invoked automatically early in
the execution) that will run through the checks (one original and couple
of new ones as of this changeset).
Note that for libqb users, this implies a new link dependency on libdl,
because they may opt-in for refreshed QB_LOG_INIT_DATA sanity check that
calls out to dlopen/dlsym/dladdr directly in case of "attribute section"
being available for the particular platform, and hence immediately needs
those symbols resolved in link time. Hence, add this conditional link
dependency to libqb.pc pkg-config file under Libs variable -- we
actually restore the occurrence of "-ldl" there as it used to be present
until commit 56754d0. While doing so, also move immediate link
dependencies of libqb (if any, currently not but that may be
a regression arising from the cleanup related to the mentioned commit)
represented with the LIBS autoconf variable under Libs.private variable
in libqb.pc, where it belongs per pkg-config documentation.
The promised table follows, but first as a recap, "X(Y)" denotes
"X linked with linker Y":
X(a) .. ld.bfd < 2.29
X(b) .. ld.bfd = 2.29 (and only 2.29)
goes like this (values in <angle brackets> denote non-trivial change
[not mere rewording] introduced as of this commit, in comparison to
the table stated in the preceding commit):
+=========+=========+=========+=========+=========+=========+=========+
#client(x)# libqb(a) usage # libqb(b) usage #
# vvv #---------+---------+---------+---------+---------+---------+
# V # direct | libX(a) : libX(b) # direct | libX(a) : libX(b) #
+=========+=========+=========+=========+=========+=========+=========+
# x = a # OK | OK : BAD[*2] #<BAD[*E]>|<BAD[*F]>:<BAD[*G]>#
# x = b # BAD[*A] | BAD[*B] : BAD[*C] #<BAD[*E]>|<BAD[*F]>:<BAD[*G]>#
+=========+=========+=========+=========+=========+=========+=========+
Woefully, nothing changes if we swap binutils 2.29 for 2.29.1, i.e.,
X(b) .. ld.bfd = 2.29.1, compared to previous state, i.e., the second
table from the previous commit is still applicable for that situation.
The added sanity checks are useful nonetheless, consider for example,
that attribute-section-less libqb is what gets run-time linked to an
attribute-section-full target. The most precise check we could use
-- a custom logger function applied in a self-test scheme -- is not
available at the point the macro-defined function gets invoked, simply
because qb_log_init hasn't been invoked by the time that constructor
gets triggered. However, what we can do is to add a non-trapping
libqb-residing reverse-testing of the client space that (and once it)
voluntarily initiates qb_log_init (delivering abruption all of a sudden
at some unanticipated, as opposed to a well-timed like with
constructors, execution point, seems pretty bad idea + libqb as
a library is a mere helper, not an undertaker :) -- this check then
only announces, via syslog (the only pre-enabled logging target),
the target's logging may be severed.
* * *
Hence, as a promised second step, after incorporating the syslog
change (and extending log_test_mock.sh so as to capture syslog
stream within the container), not much changes with the table above,
i.e., X(b) .. ld.bfd = 2.29:
[*A] in addition, unless QB_LOG_INIT_DATA used on client side,
syslog carries this notice:
"(libqb) log module hasn't observed target chain supplied callsite
section, target's and/or libqb's build is at fault, preventing
reliable logging (unless qb_log_init invoked in no-custom-logging
context unexpectedly, or target chain built purposefully without
these sections)"
logged by libqb proper
[*C] in addition, unless QB_LOG_INIT_DATA used on interlib side,
syslog carries this notice:
"(libqb) log module hasn't observed target chain supplied callsite
section, target's and/or libqb's build is at fault, preventing
reliable logging (unless qb_log_init invoked in no-custom-logging
context unexpectedly, or target chain built purposefully without
these sections)"
logged by libqb proper
[*E] in addition, unless QB_LOG_INIT_DATA used on client side,
syslog carries this warning:
"(libqb) log module has observed target chain supplied section
unpopulated, target's and/or libqb's build is at fault, preventing
reliable logging (unless qb_log_init invoked in no-custom-logging
context unexpectedly)"
logged by libqb proper
[*F] in addition, unless QB_LOG_INIT_DATA used on interlib side,
syslog carries this warning:
"(libqb) log module has observed target chain supplied section
unpopulated, target's and/or libqb's build is at fault, preventing
reliable logging (unless qb_log_init invoked in no-custom-logging
context unexpectedly)"
logged by libqb proper
[*G] in addition, unless QB_LOG_INIT_DATA used on interlib side,
syslog carries this warning:
"(libqb) log module has observed target chain supplied section
unpopulated, target's and/or libqb's build is at fault, preventing
reliable logging (unless qb_log_init invoked in no-custom-logging
context unexpectedly)"
logged by libqb proper
but desirably changes with "X(b) .. ld.bfd = 2.29.1" one
(DEP ~ "depends"):
+=========+=========+=========+=========+=========+=========+=========+
#client(x)# libqb(a) usage # libqb(b) usage #
# vvv #---------+---------+---------+---------+---------+---------+
# V # direct | libX(a) : libX(b) # direct | libX(a) : libX(b) #
+=========+=========+=========+=========+=========+=========+=========+
# x = a # OK | OK : DEP[*J] #<BAD[*M]>|<BAD[*M]>:<BAD[*L]>#
# x = b #<DEP[*N]>| DEP[*I] :<DEP[*O]>#<BAD[*M]>|<BAD[*M]>:<BAD[*L]>#
+=========+=========+=========+=========+=========+=========+=========+
* * *
[*1] client logging not working
[*2] interlib logging not working
[*3] both client and interlib logging not working
[*A] boils down to [*1], unless QB_LOG_INIT_DATA used on client side,
which then fails on
"implicit callsite section is populated, otherwise target's build
is at fault, preventing reliable logging"
assertion
[*B] boils down to [*1], unless QB_LOG_INIT_DATA used on interlib side,
which then fails on
"implicit callsite section is populated, otherwise target's build
is at fault, preventing reliable logging"
assertion
[*C] boils down to [*3], unless QB_LOG_INIT_DATA used on interlib side,
which then fails on
"implicit callsite section is populated, otherwise target's build
is at fault, preventing reliable logging"
assertion
[*E] boils down to [*1], unless QB_LOG_INIT_DATA used on client side,
which then fails on
"implicit callsite section is self-observable, otherwise target's
and/or libqb's build is at fault, preventing reliable logging"
assertion
[*F] boils down to [*3], unless QB_LOG_INIT_DATA used on interlib side,
which then fails on
"libqb's callsite section is populated, otherwise libqb's build is
at fault, preventing reliable logging"
assertion
[*G] boils down to [*3], unless QB_LOG_INIT_DATA used on interlib side,
which then fails on
"implicit callsite section is self-observable, otherwise target's
and/or libqb's build is at fault, preventing reliable logging"
assertion
[*I] boils down to [*1], unless QB_LOG_INIT_DATA used on client side,
which makes it, likely through self-reference keepalive (see
below), work OK
[*J] boils down to [*2], unless QB_LOG_INIT_DATA used on interlib side,
which makes it, likely through self-reference keepalive (see
below), work OK
[*K] boils down to [*3]
in addition, syslog carries this notice:
"(libqb) log module hasn't observed target chain supplied callsite
section, target's and/or libqb's build is at fault, preventing
reliable logging (unless qb_log_init invoked in no-custom-logging
context unexpectedly, or target chain built purposefully without
these sections)"
logged by libqb proper
[*L] boils down to [*3], unless QB_LOG_INIT_DATA used on interlib side
(sufficient?), which makes it, likely through self-reference
keepalive (see below), boil down just to [*1];
in addition, syslog carries this notice:
"(libqb) log module hasn't observed target chain supplied callsite
section, target's and/or libqb's build is at fault, preventing
reliable logging (unless qb_log_init invoked in no-custom-logging
context unexpectedly, or target chain built purposefully without
these sections)"
logged by libqb proper
[*M] boils down to [*1];
in addition, syslog carries this notice:
"(libqb) log module hasn't observed target chain supplied callsite
section, target's and/or libqb's build is at fault, preventing
reliable logging (unless qb_log_init invoked in no-custom-logging
context unexpectedly, or target chain built purposefully without
these sections)"
logged by libqb proper
[*N] boils down to [*M], unless QB_LOG_INIT_DATA used on client side,
which makes it, likely through self-reference keepalive (see
below), work OK
[*O] boils down to [*K], unless QB_LOG_INIT_DATA used on both client
and interlib side, which makes it, likely through self-reference
keepalive (see below), work OK (it's expected that this a mere
composite of situations [*I] and [*J] with consequences as stated)
* * *
Note: the only problematic (i.e. not captured automatically by the
QB_LOG_INIT_DATA macro presumably utilized at every non-libqb logging
system participant in the form of a discrete compilation unit)
combination with 2.29 is the one intersecting at "BAD[*2]" pertaining
"everything but interlib compiled with ld.bfd < 2.29". It would, of
course, be solvable as well, but presumably not in an easy way, and
that use case should not be as frequent.
Takeway: whenever your target (library or client program) actively
utilizes logging (meaning it emits at least a single log message,
otherwise there's an imminent danger of possibly even run-terminating
false positive in the self-check mechanism!),
YOU ARE strongly ENCOURAGED TO USE QB_LOG_INIT_DATA macro function
at (exactly) one of the source code files (presumably the main one)
per respective target's compilation unit.
It will alleviate the hassles possibly caused by downgrading libqb
to the linker-vs-libqb incompatibly compiled one or in similar
circumstances arising merely from the linker behaviour change,
which the current build system/code shake is all about.
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
cdb026998f