On Sun, Sep 16, 2012 at 8:02 PM, Marvin Humphrey <[email protected]> wrote: > What really sticks in my craw is that > it's the _ELF_ rules which force it to be looked up every last access, but > it's entirely possible that the lookup won't matter in practice.
I've been reading along, and will try to put my thoughts into typed words soon. Until then, I'll just stick to this sentence. I take it you are referring to the requirement of "symbol preemption", whereby even with a module every symbol must be accessed indirectly in case some earlier library decided to override it? I don't think this is actually an ELF rule, but even if so, I think there are ways around this. Here's some background on the problem and suggested solutions: http://software.intel.com/en-us/articles/software-convention-models-using-elf-visibility-attributes/ http://www.macieira.org/blog/2012/01/sorry-state-of-dynamic-libraries-on-linux/ http://www.airs.com/blog/archives/307 The recommended approach is to use ELF symbol visibility attributes to prevent preemption and allow for optimization within the module. Since our core is one big shared object, this means that everything in core can be direct access, although runtime linked user code will still need indirection. There are some complicated options discussed in the linked articles, but for us, I think we can probably just declare all the offsets as "protected" and be 95% of the way there. If anyone ever does try to override them, the sky will (silently) fall, but everything else should just work: core at full speed, user compiled shared libraries work as you describe, which in most cases is still really fast. There are a couple other approaches that might be relevant as well, but perhaps they turned out to be dead ends "-B direct" and "prelink". I unsure about their current status, and not sure if they offer us much more than the symbol visibility does. My instinct is that they don't, but I don't understand them well. Or are you saying that all shared library globals are implicitly 'volatile' in some way? I don't think there are any preclusions against caching shared library globals in registers. Are there? --nate
