Using the "-fno-semantic-interposition" compiler option, interprocedural optimization can be enabled for exported symbols [...] The way I see it, -fno-semantic-interposition is justified by the "one definition rule" in both C and C++. Having different functions with the same (qualified) name (and signature for C++) is not allowed in a program. There is still a non-standard "back door": __attribute__((weak)). So if necessary it's still possible to define overridable functions, but other libraries can't just override anything they want. It's also kind of on-by-default in Clang (not

[...] and the linker option "-Bsymbolic(-functions)" allows symbol references inside the same object to be resolved directly instead of going through runtime relocation. [...]

However, executables have to be built with that in mind (by compiling them like PIC) to avoid features which rely on interposition, like copy relocations. The "-fno-direct-access-external-data" option achieves that FWICT. In the thread where Fangrui Song aka maskray proposed to enable these flags for building Clang [1], the time difference between -Bsymbolic and -Bsymbolic-functions was minor. For Qt it might very well look different

http://bugzilla.opensuse.org/show_bug.cgi?id=1187864 http://bugzilla.opensuse.org/show_bug.cgi?id=1187864#c1 Aaron Puchert <aaronpuchert@alice-dsl.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aaronpuchert@alice-dsl.net --- Comment #1 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- (In reply to Fabian Vogt from comment #0) literally, but Clang does IPO on default visibility functions) and on other platforms, so there is hopefully not a lot of software out there that relies on semantic interposition. though. Address uniqueness is probably not a big issue, but it certainly can be an issue, as the standards guarantee it. So I think we could enable -Bsymbolic-functions on a per-package basis, but probably not globally. Avoiding copy relocations for -Bsymbolic might be too high a price to pay, at least in general. I don't know how common default visibility variables are, and whether they're typically used more often by the library or the program. With modern libraries I'd expect there not be a lot of exported variables, so maybe it just doesn't matter that much. So I'd be in favor of enabling -fno-semantic-interposition by default, but not -Bsymbolic[-functions]. We can enable that where it matters and where we think it's safe. I played with -Bsymbolic in the LLVM build once, but I'm mostly compiling C++ where the compile jobs take so long that the initial relocation processing doesn't change much. (Since we're building LLVM with Clang, we already have IPO for default visibility functions.) [1] https://lore.kernel.org/lkml/20210501235549.vugtjeb7dmd5xell@google.com/ -- You are receiving this mail because: You are on the CC list for the bug.