Suggestion for Fedora change proposal: -Bsymbolic-functions default in LDFLAGS

[Paulo César Pereira de Andrade]

  Hi,

  Idea about @subject started with ongoing customer support case that
originated https://bugzilla.redhat.com/show_bug.cgi?id=1778236
[Problems linking to zlib corrected if zlib is linked with -Bsymbolic-functions]
when doing some research, it appears Ubuntu has it by default for
some time.

  This is currently only a suggestion and/or request for comments.
Some extra detail in https://bugzilla.redhat.com/show_bug.cgi?id=1778234
[Request For Comments: -Bsymbolic-functions in LDFLAGS by default]

  Basically, there would be a few issues, most times in broken code,
and the valid cases could be worked around removing -Bsymbolic-functions.

  The biggest advantages are far less relocations, for example, that
should mean faster load time, and avoids several issues with symbols
being clobbered by symbols from another library.

Thanks!
Paulo

[Igor Gnatenko]

Do you have some benchmark results and/or some statistics related to
the file size?

On Wed, Dec 4, 2019 at 2:09 PM Paulo César Pereira de Andrade
<paulo.cesar.pereira.de.andrade(a)gmail.com&gt; wrote:
>
>   Hi,
>
>   Idea about @subject started with ongoing customer support case that
> originated https://bugzilla.redhat.com/show_bug.cgi?id=1778236
> [Problems linking to zlib corrected if zlib is linked with -Bsymbolic-functions]
> when doing some research, it appears Ubuntu has it by default for
> some time.
>
>   This is currently only a suggestion and/or request for comments.
> Some extra detail in https://bugzilla.redhat.com/show_bug.cgi?id=1778234
> [Request For Comments: -Bsymbolic-functions in LDFLAGS by default]
>
>   Basically, there would be a few issues, most times in broken code,
> and the valid cases could be worked around removing -Bsymbolic-functions.
>
>   The biggest advantages are far less relocations, for example, that
> should mean faster load time, and avoids several issues with symbols
> being clobbered by symbols from another library.
>
> Thanks!
> Paulo
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]

[Paulo César Pereira de Andrade]

Em qua., 4 de dez. de 2019 às 10:11, Igor Gnatenko
<ignatenkobrain(a)fedoraproject.org&gt; escreveu:
>  Do you have some benchmark results and/or some statistics related to
>  the file size? 
  Mostly a guess it should load faster. With 'readelf -r', standard
libz.so.1 in rhel7 shows 46 relocations, and with -Bdynamic-functions
it shows 17 relocations.

  This email is more of a heads up, starting from the customer case
with issues with zlib. Zlib also has problems, at least in rhel7, that
it does not have some symbols versioned, and if there is another symbol
with the same name, it will pick the wrong symbol (at least in the
customer environment).

> On Wed, Dec 4, 2019 at 2:09 PM Paulo César Pereira de Andrade
> <paulo.cesar.pereira.de.andrade(a)gmail.com&gt; wrote:
> >
> >   Hi,
> >
> >   Idea about @subject started with ongoing customer support case that
> > originated https://bugzilla.redhat.com/show_bug.cgi?id=1778236
> > [Problems linking to zlib corrected if zlib is linked with
-Bsymbolic-functions]
> > when doing some research, it appears Ubuntu has it by default for
> > some time.
> >
> >   This is currently only a suggestion and/or request for comments.
> > Some extra detail in https://bugzilla.redhat.com/show_bug.cgi?id=1778234
> > [Request For Comments: -Bsymbolic-functions in LDFLAGS by default]
> >
> >   Basically, there would be a few issues, most times in broken code,
> > and the valid cases could be worked around removing -Bsymbolic-functions.
> >
> >   The biggest advantages are far less relocations, for example, that
> > should mean faster load time, and avoids several issues with symbols
> > being clobbered by symbols from another library.
> >
> > Thanks!
> > Paulo
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> > Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]

[Tom Hughes]

On 04/12/2019 12:58, Paulo César Pereira de Andrade wrote:

>     Idea about @subject started with ongoing customer support case
> that
>  originated https://bugzilla.redhat.com/show_bug.cgi?id=1778236
>  [Problems linking to zlib corrected if zlib is linked with -Bsymbolic-functions]
>  when doing some research, it appears Ubuntu has it by default for
>  some time.
>  
>     This is currently only a suggestion and/or request for comments.
>  Some extra detail in https://bugzilla.redhat.com/show_bug.cgi?id=1778234
>  [Request For Comments: -Bsymbolic-functions in LDFLAGS by default]
>  
>     Basically, there would be a few issues, most times in broken code,
>  and the valid cases could be worked around removing -Bsymbolic-functions.
>  
>     The biggest advantages are far less relocations, for example, that
>  should mean faster load time, and avoids several issues with symbols
>  being clobbered by symbols from another library. 
If I understand correctly then it will also mean that LD_PRELOAD will
not work for any call made from the library to itself, but would still
work for calls made from other libraries.

Tom

-- 
Tom Hughes (tom(a)compton.nu)
http://compton.nu/

[Paulo César Pereira de Andrade]

Em qua., 4 de dez. de 2019 às 10:16, Tom Hughes <tom(a)compton.nu&gt; escreveu:
>  On 04/12/2019 12:58, Paulo César Pereira de Andrade wrote:
>
>  >    Idea about @subject started with ongoing customer support case that
>  > originated https://bugzilla.redhat.com/show_bug.cgi?id=1778236
>  > [Problems linking to zlib corrected if zlib is linked with -Bsymbolic-functions]
>  > when doing some research, it appears Ubuntu has it by default for
>  > some time.
>  >
>  >    This is currently only a suggestion and/or request for comments.
>  > Some extra detail in https://bugzilla.redhat.com/show_bug.cgi?id=1778234
>  > [Request For Comments: -Bsymbolic-functions in LDFLAGS by default]
>  >
>  >    Basically, there would be a few issues, most times in broken code,
>  > and the valid cases could be worked around removing -Bsymbolic-functions.
>  >
>  >    The biggest advantages are far less relocations, for example, that
>  > should mean faster load time, and avoids several issues with symbols
>  > being clobbered by symbols from another library.
>
>  If I understand correctly then it will also mean that LD_PRELOAD will
>  not work for any call made from the library to itself, but would still
>  work for calls made from other libraries. 
  Not fool proof checked, but I believe this is what would happen. Usually
one wants to only LD_PRELOAD to replace some glibc symbol, for some kind
of debug, but any library where there valid usages of LD_PRELOAD should
not be linked with -Bdynamic-functions.

>  Tom
>
>  --
>  Tom Hughes (tom(a)compton.nu)
>  http://compton.nu/ 
Thanks,
Paulo

[Petr Pisar]

On 2019-12-04, Paulo César Pereira de Andrade
<paulo.cesar.pereira.de.andrade(a)gmail.com&gt; wrote:
>  Em qua., 4 de dez. de 2019 às 10:16, Tom Hughes
> <tom(a)compton.nu&gt;
>  escreveu:
> > If I understand correctly then it will also mean that LD_PRELOAD will
> > not work for any call made from the library to itself, but would
> > still work for calls made from other libraries.
>
>    Not fool proof checked, but I believe this is what would happen.
>    Usually one wants to only LD_PRELOAD to replace some glibc symbol,
>    for some kind of debug, but any library where there valid usages of
>    LD_PRELOAD should not be linked with -Bdynamic-functions.
>  
Like when testing the compiled library in %check phase of a spec file.

-- Petr

[Dridi Boukelmoune]

>    Not fool proof checked, but I believe this is what would happen.
> Usually
>  one wants to only LD_PRELOAD to replace some glibc symbol, for some kind
>  of debug, but any library where there valid usages of LD_PRELOAD should
>  not be linked with -Bdynamic-functions. 
Having experienced the frustration of dealing with -Bsymbolic
first-hand I would strongly discourage adding that kind of link
behavior downstream, and if it happens to come from upstream I would
strongly advocate to encourage the upstream project to drop it.

Once a symbol is extern (or public if you prefer) it's very
inconvenient to only be able to catch *some* calls to that symbol. One
real-world use case I had for some $DAYJOB was lock contention on the
happy path during error checking. For the sake of the argument let's
call it libcontended... For the few customers that would run into this
corner case that would bring their setup to a crawl, we devised a
simple hook with LD_PRELOAD to keep track of errors and force an early
return in the offending error checking code to avoid taking the lock
when we knew for a fact that it wouldn't return anything anyway.

I voluntarily skip other gory details, but we knew that our workaround
was correct because we had access to the source code of libcontended
(free software, am I right?) but weren't in a position where we could
repackage that library. And since that lock contention problem was
solved in the next major release, we knew that at some point as
customers would eventually upgrade and leave the workaround behind.

All was well and fine until we ran into one supported OS where
libcontended was patched downstream with -Bsymbolic enabled. The
simple workaround that required us to hook two functions was no longer
working and not only that, it took us a fair amount of dumbfounding
time trying to figure why. We couldn't fix this corner case on that
OS.

I avoided name dropping on purpose, because I don't want to point
fingers, but please, reconsider doing that kind of change. If an
application ends up linking to several versions of zlib then something
very wrong is going on. Unless that application has some kind of
plugin system where two different plugins might bring two different
versions of zlib (or for that matter any library).

If you are running into that kind of problems where
plugins/modules/dynamically linked objects may have conflicting
requirements [1] then I would apply the First principle and try to
patch the plugin or whatnot that links to an older version to bring it
up to speed. If that's indeed a plugin system, it might be possible to
isolate conflicting shared objects to some extent with a flag like
RTLD_LOCAL.

Please take into consideration that resorting to -Bsymbolic might
break someone else's use case further downstream, and is technically
an ABI breakage.

Dridi

[1] by the way, equally hard to debug as the case I described above

[John Reiser]

>  If you are running into that kind of problems where
>  plugins/modules/dynamically linked objects may have conflicting
>  requirements  
then see dlmopen():  https://sourceware.org/glibc/wiki/LinkerNamespaces

[Dridi Boukelmoune]

On Tue, Dec 10, 2019 at 12:28 AM John Reiser <jreiser(a)bitwagon.com&gt; wrote:
>  > If you are running into that kind of problems where
>  > plugins/modules/dynamically linked objects may have conflicting
>  > requirements
>
>  then see dlmopen():  https://sourceware.org/glibc/wiki/LinkerNamespaces 
Agreed, my first response to this kind of problem was invoking the
First principle and as a downstream effort align both parts of the
offending application to the latest zlib, if that application is part
of the package collection.

Either way I wouldn't cripple end-users with -Bsymbolic.

And in the same spirit of the link you shared, even with -Bsymbolic
you might lose guarantees if one part of the application linked
against libz.x and the other libz.y: while intra-zlib calls may not
cross boundaries there is also no guarantee that the application part
linking against libz.x will not in fact make calls to libz.y in an
incompatible way (since SONAMEs don't match).


Dridi