Dne 07. 11. 19 v 23:08 Florian Weimer napsal(a): > * 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.
Thx for explanation Florian. Generally, I am against this change proposal, because: 1) Apparently, there is some work which needs to be done on the toolchain. Applying workarounds just hides the issues and we won't move forward ever. 2) I am asking this questions, because I believe that the same issue might suffer Ruby and others are concerned about Perl. Applying this just to Python is not systematic. However, if part of this change proposal was actually collecting the information what have to be done to have similar performance for the dynamically linked libraries comparing to static linking, if there is push to improve the toolchain and if there is generally better understanding of the issue, then I would not mind if this is accepted as temporary measure. Unfortunately, nothing like this is mentioned in the change proposal. Vít > > Thanks, > Florian _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
