On Fri, 2011-08-26 at 11:34 -0500, Jeff Weber wrote: > The Linux ELF dynamic linker/loader ld-linux.so uses a "lazy" model by > default, and defers symbol resolution, shared object resolution to the > time when the symbol is first referenced. This sounds like a large > latency threat to dynamically linked RT applications running in > primary mode. Can this happen, or is this unlikely?
Good question, I never actually measured this over an application mapping shared libs which would consist of a large number of routines called over time. I would tend to think that ld.so's symbol lookup routine might represent the highest risk for significant latency, if any, because all the rest, i.e. GOT, PLT and the code itself should have been read in and processed at program init, either by ld.so or as a result of mlocking the program. Running the trampoline code from the PLT and fixing up the GOT with the indirect jump address after symbol resolution should not entail significant latency either, so the real issue, if any, might be introduced by the lookup code actually resolving the symbols. I would think that all the data is already there, available to ld.so for this operation, and the ELF format mandates that dynamic symbol names be hashed for fast retrieval. However, I may be wrong, this needs to be verified. > > > If this is a latency risk, the only solutions I know of are: > > > 1) Statically link all RT applications > > > 2) Invoke all dynamically linked applications with LD_BIND_NOW=1 > environment to force the dynamic loader to resolve all symbols at > program startup > > > 3) Link dynamic applications with "-z now" GNU ld option to effect > same as 2) above. > > > Comments? > In short, my understanding is that we should not see significant extra latency, unless ld.so does on demand loading of portions of the ELF tables/sections it needs for symbol resolution, instead of loading these tables at program init. This seems unlikely though. > > thanks, > Jeff > _______________________________________________ > Xenomai-help mailing list > [email protected] > https://mail.gna.org/listinfo/xenomai-help -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
