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