Reducing the libxul export list
In a (very hacked up) local tree, I’ve got the export list from libxul reduced to something almost-reasonable: 619 exports on win32 and 793 exports on linux. Quite a few of those are XPTCStubBase and can be removed, and there’s also some zlib and NSS symbols which I haven’t figured out how to hide yet. But we’re getting closer!
March 30th, 2006 at 1:04 am
So, is XPTCStubBase and the rest of the xptcall system going to be available in the form of a static library? Or, is it going to be exposed in some other way so that someone could create a new language binding for libxul? Personally, I’d prefer to see some stable API exposed by libxul (or better yet, via libxpcom).
March 30th, 2006 at 8:24 am
/me cheers bsmedberg on
March 30th, 2006 at 8:24 am
How to hide? In gcc, through a linker script. Here’s an example:
http://www.mozdev.org/source/browse/moztraybiff/source/components/libtraybiff.version_script?content-type=text/x-cvsweb-markup
(you might want to make your logic reverse – global * and local a bunch of zlib and NSS symbols)
And here’s the changes to the Makefile:
http://www.mozdev.org/source/browse/moztraybiff/source/components/Makefile.diff?r1=1.8&r2=1.9&f=h
March 30th, 2006 at 9:29 am
Darin, I’d like xptcall to be made available as frozen exports from libxul. I don’t have a good handle yet on what that actually entails: do the current xptcall users link against the XPTCStubBase symbols (which are mangled C++ and therefore not freezable), or just the C function symbols?
Ilya, linker scripts don’t actually provide the runtime benefits of symbol-hiding: if the compiler knows that the symbol is hidden it can avoid calling the symbol through the PLT, which in many cases means that the function doesn’t need to load the PIC register at all. See http://people.redhat.com/drepper/dsohowto.pdf for more details.