https://bugzilla.suse.com/show_bug.cgi?id=1187864 https://bugzilla.suse.com/show_bug.cgi?id=1187864#c3 --- Comment #3 from Michael Matz <matz@suse.com> --- As I wrote to maskray on the generic-abi list ( https://groups.google.com/g/generic-abi/c/LgSC6te51uM/m/WGzfjtFKAgAJ ) I'm quite heavily opposed to disabling interposition wholesale. I would perhaps support it when restricted to C++ symbols for functions. Also note that protected visiblity is going to be fixed on x86-64 (to not be worse than default visibility and break with copy relocations, i.e. it will work again like before 2014/15) over the next months. At that point packages choosing so can simply use that. -Bsymbolic should be regarded as a hack in the ELF world, because ELF has symbol visibility which is (or was, and will be again) designed to be exactly that. And of course the compiler doesn't know anything about it, so can't base it's inlining decisions on it. (Which is the whole reason why people had to invent still another flag for the compiler; well, that and because protected visibility wasn't working as designed/desired). So, my course of action would be: wait for protected symbol visibility to be fixed again, make it so that packages can select that visibility as default for C++ functions (select it in a way the compiler knows), let packages decide. Possibly make that default in the toolchain after quite some time. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1187864 https://bugzilla.suse.com/show_bug.cgi?id=1187864#c7 --- Comment #7 from Michael Matz <matz@suse.com> --- Normally I do like language lawyering very much, but I think in this case it's not appropriate. Symbol interposition is an ELF feature, and hence, for us, a system feature; a fairly powerful one with some disadvantages. We can't just disable that feature after 30 years. At least not if there are ways where we can mitigate the disadvantages without throwing out the baby completely. Aaron: the power of interposition doesn't lie in being able to override known symbols, but rather to override _all_ (exported) symbols. The point being that the software authors don't have to explicitely mark symbols as overridable; if they were to be required to do that, that wouldn't then make it different from them explicitely designing hooks into their interfaces. There is for instance software that hooks many libc routines (and a changeable set of other routines) in order to, well, hook them (e.g. for tracing). Symbol interposition makes this trivial. Without it you need to resort to the contortions that equivalent Windows software needs to go through (basically patching either the import table, if it exists, or even the function code itself). Basically: if library authors would be required to make their exports hookable, we would end up with nothing being hookable. That is because the need for hooking can't be predicted; if someone needs it, it's usually not the library author but someone outside who doesn't necessarily (want to) have means to change the library. As I've written elsewhere (probably in the above generic-abi thread): I'll concede that such hooking usually takes place for C symbols, not for other language symbols. (Though of course there's nothing that would currently prevent that, and of course e.g. valgrind does hook the global c++ allocation routines). So, I'd be willing to try disabling interposition for C++ symbols (with exceptions). But before even that, we need to be clear what exactly we want to change and what the improvements of that change will be. Perhaps on a bit more than just clang (speedup due to fewer symbol lookups) and some anecdote from the web about cpython. (FWIW: I do know that libqt also goes to lengths to reduce symbolic lookups, and libreoffice (at the time still openoffice) had the same problem, which is why we now have .gnu.hash, and KDE had the problem which is why we have (had) kdeinit. I.e. I know that symbolic lookups are a problem for some software (all C++!) but I also know that it's absolutely no problem at all for other software, which is why I'm hammering so much on the protected visibility, being _exactly_ the right tool for avoiding symbolic lookups from within shared libs) And yes, Aaron: the idea for "fixing" protected vis is to not generate copy relocs for variables (i.e. cross module accesses will be indirect, like now but in the other direction). For function addresses something similar can be done; it must be the one from the defining module, not from the PLT slot in the exe. H.J. works on some patches that try to phase that into the world step by step to not break existing binaries. -- You are receiving this mail because: You are on the CC list for the bug.