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.
Showing
想要评论请 注册 或 登录