ideal visibility setting?

Jay K jay.krell@cornell.edu
Mon May 17 13:09:00 GMT 2010


We generate gcc trees.
 
 
I'm aware of "visibility"
  Is something exported or not?
  If it is exported, do I reference it "directly" or allow for interposition?
 
  
What I would like is..basically the NT model, but without __declspec(dllimport)
    which is "just" an optimization for functions, but, granted,
    more than that for data.
  I promise not to import/export data.
  I want all symbols, for codegen purposes, to be default assumed to be
    neither exported nor imported. I want to reference functions directly.
    No GOT or PLT references in the "main" code.
    No "interposition".
 
 
  If I mark a function somehow as exported, I want that just to be a note
    to the linker.
 
 
  If the linker resolves a function against a shared object, I want
    it to generate a little stub that does the necessary indirection.
 
 
 I'm assuming that most inter-function calls are intra-shared object.
 To the extent that that is true, this is simple and efficient.
 To the extent that that is false, it is a deoptimization.
 It absolves anyone from knowing at compile time which functions are where.
 
 
 This is how things work on NT and it seems nice.
   I realize NT doesn't offer position independence, so the use
     of linker generated stubs would be more inefficient in
     what I am describing, vs. inlining them at the call site.
     But again, I'm optimizing for the intra-shared object references
     which I assume are more common.
 
 
 Any ideas how to achieve this?
 
 
I hit problems before getting very far.
When I mark functions as VISIBILITY_PROTECTED, references within the same
objecte file still use the GOT and I get:
 
 
/usr/bin/ld: Region.mo: relocation R_386_GOTOFF against protected function `Region__Meet' can not be used when making a shared object
/usr/bin/ld: final link failed: Bad value
 
 
Thanks,  
  - Jay
 		 	   		  



More information about the Gcc-help mailing list