Hi,
As importing third-party code into libxul seems to be pretty popular,
I wanted to point out something that's easy to overlook.
Libraries usually have code that goes like:
#ifdef _WIN32
#define MYLIB_EXPORT __declspec(dllexport)
#else
#define MYLIB_EXPORT __attribute__((visibility("default")))
#endif
MYLIB_EXPORT int MyLibrary_DoTheThing() { return 42; }
This makes perfect sense when upstream builds their product as
MyLibrary.dll, as those APIs need to be callable from the outside
world. But when we paste the code into libxul, and its callers are
also in libxul, there is no need to cross a library boundary.
Exporting those symbols when not needed is harmful for several reasons:
* It prevents optimization and/or increases code size. The compiler
has to choose between keeping a single copy of the function with the
shape demanded by the ABI, which inhibits interprocedural
optimizations; or creating optimized/inlined copies but keeping the
original just in case the outside world ever calls it.
* It attracts wrongful blame in crash stacks. In cases where a
debugger doesn't have access to symbols, it will guess an
instruction's function based on the nearest exported symbol. This
often makes it look like function_that_landed_last_week+0x12345 caused
a crash, which wastes time with a wild goose chase.
* Exported symbols invite function hooks from questionable software.
I've filed bug 1523352 to see if we can keep track of export table
size in Perfherder similar to the existing section size metrics.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
