Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Med: add extra run-time (client, libqb) checks that logging will work
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ý <[email protected]>
- Loading branch information
