diff options
author | Rich Felker <dalias@aerifal.cx> | 2017-08-11 00:17:00 -0400 |
---|---|---|
committer | Rich Felker <dalias@aerifal.cx> | 2017-08-11 00:17:00 -0400 |
commit | dc2f368e565c37728b0d620380b849c3a1ddd78f (patch) | |
tree | 670c8185a57f03ca9779ef87f3bb834f2799fcd8 /src | |
parent | 947d330f68c49680dcc54439f56da2a297228962 (diff) | |
download | musl-dc2f368e565c37728b0d620380b849c3a1ddd78f.tar.gz |
disable global visibility override hack (vis.h) by default
neither current compilers nor linkers treat protected visibility the
way I expected, as having fixed source-level semantics rather than
being dependent on target-specific ABI details, and change seems
unlikely. while the use here does not actually depend on the specific
semantics, at least some versions of some linkers, especially lld,
refuse to allow linking to a libc.so where the symbols have protected
visibility. this cannot be detected at configure-time because linking
libc.so itself works fine, and because even if we could test linking
an application against libc.so successfully, we could not justifiably
assume that the same linker used to link libc.so would also be used
later to link applications.
disable the vis.h hack by default at the configure level, but add an
explicit "auto" option to request the old configure-time detection
rather than just removing it. this leaves it easy to evaluate whether
it actually resulted in significant size or performance benefits while
ensuring that out-of-the-box builds are not unlinkable for some users.
fortunately, preliminary evaluation suggests that at least x86_64,
arm, and aarch64 don't suffer at all from the change, and impact on
other archs is low. if low is not low enough, it should not be hard to
analyze where the significant PLT call ABI costs are present and
mitigate them without the hack.
Diffstat (limited to 'src')
0 files changed, 0 insertions, 0 deletions