On Tue, Jun 03, 2014 at 12:08:52PM -0400, Ehsan Akhgari wrote: > On 2014-06-03, 5:57 AM, Henri Sivonen wrote: > >On Wed, May 28, 2014 at 5:45 PM, Nathan Froyd <froy...@mozilla.com> wrote: > >>Assuming that ICU is already compiled with the moral equivalent of GCC's > >>-ffunction-sections -fdata-sections or MSVC's /Gy, then statically linking > >>ICU into libxul should already strip out all the un-needed ICU bits (when > >>using the appropriate linker option). > > > >Disabling ICU IDNA code made libxul smaller, so it seems practice > >doesn't match the above theory. (I.e. clearly the linker wasn't > >automatically dropping ICU IDNA code.)
Well, was this tested in a local build, or ones done in automation? We don't seem to pass --gc-sections to the linker on local builds presumably to make builds faster. > The linker can only eliminate symbols that are not referenced by anything > else. Basically the linker creates a graph and preserves everything that is > referenced by some roots, for example, main, static initializers, and very I'd expect static initializers don't get explicitly added to the set of roots since they should be rooted through .init_array / .ctors. This also misses that function exported from the library are obviously roots. and ICU exports a *ton* of symbols from libxul which I'm trying to fix for ELF targets in bug 1019744. > importantly, vtables. So, anything that is a virtual function or is > referenced by one will remain in the binary even if there is no code > _calling_ that virtual function anywhere. I'd expect that vtables aren't special if there class is hidden and you can gc all the references in the library to the vtable then you can gc the vtable too because nobody can get at it. If the class isn't local then you have to keep the vtable, but that would be true anyway because its a global symbol. Trev > > Cheers, > Ehsan > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform
signature.asc
Description: Digital signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
