Jay K <jay.krell@xxxxxxxxxxx> writes: > The vast majority of functions are never interposed (right?), yet, > it seems, basically every function call pays a price (right?). :( By default, the first time a call is made to a globally visible function from a shared library, the dynamic linker does a lookup on the symbol name to see if there is any interposition. That is costly, yes. The second and subsequent times that function is called, the cost is approximately three additional instructions, including an additional memory load into the instruction cache and another memory load of the function address out of the GOT. It's not ideal but it's not too bad. Using the prelinker can avoid the heavy cost of the first call to the function. > ELF's simple "everything works, no annotations, including data > imports/exports, and interpositioning of data and functions" seems > costly, and seems to have "fallen out of favor" -- you know, > -fvisiblity=hidden being encouraged implies the ELF model isn't > ideal. Different people have different needs. The point of something like -fvisibility=hidden is to give people a simple way to control the visibility of internal symbols. That is, a shared library should only expose (and permit interposition for) its defined API. Internal symbols within the shared library should be hidden, so that other programs can not accidentally call them. This can be done using a version script at link time. -fvisibility=hidden lets you do it entirely in the source code without using a separate script. > It's kind of like, you know.. "add too many features by default, > that are difficult to implement efficiently, and then work extra > hard to regain efficiency through tweaks like -fvisibility=hidden, > -B symbolc, etc." To me it's more like "implement a simple and easy to describe system by default, and permit knowledgeable users to tweak it." I understand that different people have different opinions. Systems without symbol interposition tend to have what I consider to be odd semantics, such as having two different global functions with exactly the same name and complex rules about which one is called depending on which shared library is doing the calling. That kind of thing is OK if you know what you are doing but it seems like an odd choice for default behaviour. Ian
