[ClusterLabs Developers] [libqb] heads-up: logging not working with binutils-2.29 standard linker (ld.bfd)

[Jan Pokorný]

On 19/10/17 22:49 +0200, Jan Pokorný wrote:
> On 03/08/17 20:50 +0200, Valentin Vidic wrote:
>>> Proper solution:
>>> - give me few days to investigate better ways to deal with this
> 
> well, that estimate was off... by far :)
> 
> But given the goals of
> - as high level of isolation of the client space from the linker
>   (respectively toolchain) subtleties as possible (no new compilation
>   flags an such on that side)
> - universality, as you don't really want to instruct libqb users
>   to use this set of flags with linker A and this with linker B,
>   and there's no way to hook any computational ad-hoc decision
>   when the compilation is about to happen (and particular linker
>   to be used + it's version are quite obscured in the build pipeline
>   so only configure-like checks would be viable, anyway)
> - mapping the exact scope of the issue for basic combinations of
>   link participants each doing the logging on its own and possibly
>   differing in the linker used to build them into standalone shared
>   libraries or executable using the former + cranking up the runner
>   of the underlying test matrix
> - some reasonable assurance that logging is not silently severed (see
>   the headaches note below)

I would have forgotten the uttermost important one(!):
- BINARY COMPATIBILITY (ABI) is PRESERVED, except for a single "ABI
  nongracefulness" I am aware of but that's more a consequence of
  slightly incorrect assumptions in the logic of QB_LOG_INIT_DATA
  macro function predating this whole affair by a long shot and which
  the patchset finally rectifies:
  if in the run-time dynamic link, following is combined:
  (. libqb, arbitrary variant: pre-/post-fix, binutils < / >= 2.29)
  . an "intermediate" library (something that the end executable links
    with) triggering QB_LOG_INIT_DATA macro and being built with
    pre-fix libqb (and perhaps only with binutils < 2.29)
  . end executable using no libqb's logging at all, but being built
    with post-fix libqb (and arbitrary binutils < / >= 2.29)
  then, unlike when executable is built with pre-fix libqb, the
  special callsite data containing section in the ELF structure
  of the executable is created + its boundary denoting symbols
  defined within, despite the section being empty (did not happen
  with pre-fix libqb), and because the symbols defined within the
  target program have priority over that of shared libraries in the
  symbol resolution fallback scheme, the assertion of QB_LOG_INIT_DATA
  of the mentioned intermediate library will actually be evaluating
  the inequality of boundaries for the section of the executable(!)
  rather than it's own (or whatever higher prio symbols are hit,
  presumably only present if the section at that level is non-empty,
  basically a generalization of the story so far);

  the problem then manifests as unability to run said executable
  as it will fail because of the intermediate library inflicted
  assertion (sadly with very unhelpful "Assertion `0' failed"
  message);

  fortunately, there's enough flexibility so as how to fix
  this, either should be fine:
  . have everything in the executable's library dependency closure
    that links against libqb assurably linked with one variant of
    libqb only (either all pre-fix or post-fix)
  . have the end executable (that does not use logging at all as
    discussed precondition) linked using substitution like this:
    s/-lqb/-l:libqb.so.0/  (you may need to adapt the number later)
    and you may also need to add this CPPFLAG for the executable:
    -DQB_KILL_ATTRIBUTE_SECTION

* * *

Note: QB_LOG_INIT_DATA macro is not that widespread in the client
      space (though pacemaker uses it and corosync did use an internal
      variant that's hopefully ditched in favour of the former:
      https://github.com/corosync/corosync/pull/251) but I would
      recommend using it anywhere the logging is involved as it
      helps to check for preconditions of functional logging
      early at startup of the executable -- hard to predict
      what more breakage is to come from the linker side :-/
      (and on that note, there was an attempt to reconcile
      linker changes in the upstream I had no idea about
      until recently:
      https://github.com/ClusterLabs/libqb/pull/266#issuecomment-337700089
      but only limited subset of the behaviour was restored, which
      doesn't help us with libqb and binutils 2.29.1 still enforces
      us to use the workaround for 2.29 -- on the other hand, no new
      breakage was introduced, so the coexistence remains settled
      as of the fix)

> I believe it was worth the effort.
> 
>>>   fancy linker, it will likely differ from the iterim one above
>>>   (so far, I had quite miserable knowledge of linker script and
>>>   other internals, getting better but not without headaches);
>>>   we should also ensure there's a safety net because realizing
>>>   there are logs missing when they are expected the most
>>>   ... priceless
>> 
>> Thank you for the effort.  There is no rush here, we just won't
>> be able to upload new version to Debian unstable.
> 
> The reconciling patchset is not merged yet, but I'd say it's in the
> good shape: https://github.com/ClusterLabs/libqb/pull/266
> 
> Testing is requested, of course ;)

(see also:
https://github.com/ClusterLabs/libqb/pull/266#issuecomment-337700089)

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/developers/attachments/20171020/d44ecd7a/attachment-0004.sig>