On Friday, April 29, 2011 7:18:47 AM Marcus Meissner wrote:
If they are not declared hidden, the -fPIC compile generates PLT relocations for those symbols, even if they are internal to the dll (the compiler does not know what to export during our build).
With the hidden attribute these get turned into just relative calls or simpler relocations.
Wouldn't it be better to compile with -fvisibility=hidden, then? Default to hidden, then explicitly mark the functions that can be exported from the .so (if Wine even needs PE exports to have "default" visibilty; I don't think it does). Functions that are *never* called from outside the module may be better marked as "internal":
"Internal visibility is like hidden visibility, but with additional processor specific semantics. Unless otherwise specified by the psABI, GCC defines internal visibility to mean that a function is never called from another module. Compare this with hidden functions which, while they cannot be referenced directly by other modules, can be referenced indirectly via function pointers. By indicating that a function cannot be called from outside the module, GCC may for instance omit the load of a PIC register since it is known that the calling function loaded the correct value." http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Function-Attributes.html#Functio... Attributes
FWIW, you can even mark COM functions as "hidden". As noteded above, hidden functions can still be called from the outside (through function pointers, like vtables), they just aren't able to be directly referenced.