[Xfce-bugs] [Bug 5887] Add support for -Bsymbolic-functions to LD checks

[bugzilla-daemon at xfce.org]

http://bugzilla.xfce.org/show_bug.cgi?id=5887

--- Comment #14 from Brian J. Tarricone <bjt23 at cornell.edu> 2009-10-22 14:50:36 PDT ---
Is it actually hard to measure?

It's true that I don't really want to change it because what we have seems to
work fine, and there's some risk in changing it.  But it's a question of the
benefit: if you're going to propose a change, then the burden is on your
shoulders to prove that there's actually a benefit.

Do you know how to benchmark this?  If not, then you're just making a baseless
claim about some unknown performance case.

The only evidence of improvement you've provided is a 6% decrease (less than
2kB) in binary size for a single (relatively small 260kB) library.  Not only is
it an unreliable sample, I just don't think saving 6% (assuming it's 6% for
every single library, which I doubt) of our total shared library footprint is
all that impressive.

If you prefer to use --version-script, why not just generate the .ver file from
the .symbols file (or vice versa)?

Also note that -Bsymbolic isn't about reducing PLT entries.  It does do that as
a side-effect, but its purpose is to bind symbol definitions so they can't be
overridden.

The modern/correct way of defining the public ABI is through visibility
attributes.  The version script method is also correct, though maybe "the old
way" (not that there's anything wrong with that).  -Bsymbolic has nothing to do
with ABI.  The safest way to reduce PLT entries is with the aliasing trick.

Performance wise, I can't really say too much, but I'd guess there's less of a
win here than you'd think.  To call shared lib functions, the application
*still* has to call into the GOT.  Just with -Bsymbolic, instead of resolving
the function address with GOT+PLT, it should get resolved with GOT+a static
offset.  This offset still needs to be determined, so you're not speeding up
initial application load time (the relocation still has to happen anyway).

As for actual calls to the function, I'm not sure how the runtime linker
handles this.  Either it will more or less generate a PLT on the fly (which is
why the .so size is smaller), or it'll patch references in the binary at
callsites with GOT+offset either at load time or on first call.  If it does the
former, I don't think there's really any benefit.  If the latter, successive
calls to the function should be faster, but I'm not sure how much.

Anyway, that's all hand-wavy from memory and intuition (haven't looked at this
stuff in years), so I might be off on how that works.  But still, that doesn't
really change the fact that the benefit seems negligible (pending proof either
way), and what we have works well enough already.

Now, if you're saying the alias stuff is a pain to set up, I'd certainly agree.
 But that doesn't justify throwing away the stuff that's already set up.  I
believe the script that generates the alias .c/.h files is in perl... if that
could be rewritten in portable sh, we could stuff that in x-d-t as well, and
then just require that the maintainer:

1.  Put the macro in configure.ac
2.  Maintain a file with a list of exported symbols
3.  Put a rule substitution in the Makefile.am (similar to
@INTLTOOL_DESKTOP_RULE@) that generates the alias .c/.h files
4.  Include the files in the appropriate .c files.

That would maintain the status quo with regard to functionality, but make
setting up new libraries easier.  The only annoying bit is #4, but maybe we can
come up with a workaround for that, too.

-- 
Configure bugmail: http://bugzilla.xfce.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.