* Vít Ondruch: > Dne 07. 11. 19 v 16:05 Tom Hughes napsal(a): >> On 07/11/2019 14:59, Victor Stinner wrote: >> >>> I cannot explain why PLT is needed when a libpython function calls a >>> libpython function. >> >> Because an exported symbol in an ELF shared library is subject to >> potential interposition using LD_PRELOAD so the calls need to go >> through the PLT to be resolved. > > > Not sure what PLT is (pre load table?), but is it something what could > be disabled? Procedure Linkage Table. It can be disabled by using hidden symbols. For internal symbols, that is easy. For symbols that are used externally, I do not think we have good toolchain support. Link-time optimization can detect truly internal symbols and make them hidden. Some targets can also perform relaxation of relocations, eliminating most of the PLT indirection overhead if it turns out a function is not exported after all and therefore cannot be interposed. But that needs a version script, and it can't work for calls to functions that are in fact public. In glibc, we create hidden aliases for public functions which should not be interposed. It's not too bad if you have preprocessor macros for this task, but you do need to annotate each function declaration and definition separately. > This sounds like the whole system could be 25% faster if we link > statically. Not reallly, quite a few system components already do this kind of optimization. Toolchain support for this is quite poor however. Ideally, we would have a compilation mode that reuses the annotations that Windows uses, but given that our system headers currently lack __dllimport specifiers (or whatever they are called), even with that approach, it's quite a lot of work. I might be mistaken about this, but I think there was a huge conflict about some intermediate visibility setting (protected?) that might help with this, basically creating non-interposable function symbols, but I don't think it's usable for that in its current state. Thanks, Florian _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
