RE: ideal visibility setting?

[Jay K <jay dot krell at cornell dot edu>]

Global variables I'm willing to live with whatever -fPIC needs and/or annotate imports.
Maybe removing interpositioning can make it more optimal but I don't have the details (of x86 addressing modes and the -fPIC form, could be that -fPIC deoptimization is as much as dynamic linking and interpositioning deoptimization so nothing to gain).
 
 
 
I'm willing to have no data imports/exports and no interpositioning, but agreed -fPIC still would have to do something.
 
 
 
It is function calls where "I know nothing is needed".

 
The vast majority of functions are never interposed (right?), yet, it seems, basically every function call pays a price (right?). :(
 
 
Do people interpose for "occasional" debugging/diagnostics/timings, or even often in production and want it to be optimized?
  I guess timings vs. optimized is a problem. Measuring time will always slow things down but you want to minimize that.
 
 
 
You could generate TEXTREL-ish data that only gets use if an interposition is found -- that is, go through the usual resolution, but if the resolution is to within the .so, the code remains asis, readonly, position independent, no indirection. If the function is resolved to outside the .so, patch the instruction.
 
 
 
That would be ok if interposition is rare.
  If interposition is common, you wouldn't want so many TEXTRELs to actually do mprotect+write. (and again, the timing scenario -- don't want to slow things down too much because you are measuring).
 
 
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.
 
 
Apple's "two level namespace" stuff, for example, doesn't handle interpositioning, right?
You have to interpose a replacement file with the same name I imagine, with every function, not just any file with a replacement function.
Yes, I realize Apple != ELF.
 
 
And Apple's model isn't what I'm after either, there too every function call pays a price, every call is to a "stub" (that the linker generates).

 
 
Oh well, I guess one would have to write his own dynamic linker and hack the compiler a bit.
:(
 
 
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."
 
 
 - Jay


----------------------------------------
> To: jay.krell@cornell.edu
> CC: gcc-help@gcc.gnu.org
> Subject: Re: ideal visibility setting?
> From: iant@google.com
> Date: Thu, 20 May 2010 17:29:03 -0700
>
> Jay K writes:
>
>> Data accesses I would assume are almost never cross-.dso.
>> The rare ones would be source-annotated with some sort of "import",
>> and the compiler would generate less efficient but PIC code for them.
>
> First, that just isn't how ELF works. ELF has a very simple model:
> everything simply works correctly without source code annotation, and
> symbol interposition works. You are looking for a more complex model
> at the cost of adding source code annotations. That's not crazy, but
> it's not ELF.
>
> Second, I still don't understand how you can have position independent
> code on 32-bit x86 which accesses global variables but does not use a
> GOT.
>
>> This is basically the Win32/NT model and seems pretty good.
>
> The model is good until you need to use symbol interpositioning.
> Symbol interpositioning is not a bizarre technique that nobody uses.
> People use it regularly to, e.g., use debugging malloc code, or to add
> profiling timers to all network accesses.
>
> Ian