For some background: The Rust compiler will mark everything as `hidden` in LLVM IR unless it is exported via a C interface (via either #[no_mangle] or #[export_name]). So the FFI symbols in gkrust will have default visibility. LLD will thus probably retain and re-export them, even if they are not called from within libXUL. But we should double-check that.
It might be a good idea to provide a way to tell the Rust compiler to make everything `hidden` by default. On Tue, Aug 28, 2018 at 3:56 PM, Till Schneidereit < t...@tillschneidereit.net> wrote: > CC'ing mw, who is working on cross-language LTO. > > On Tue, Aug 28, 2018 at 3:20 PM Mike Hommey <m...@glandium.org> wrote: > >> On Tue, Aug 28, 2018 at 09:14:02AM -0400, Jeff Muizelaar wrote: >> > We don't LTO yet on Mac. >> >> We don't LTO across languages on any platform yet. Rust is LTOed on all >> platforms, which removes a bunch of its symbols. Everything that is >> exposed for C/C++ from Rust, though, is left alone. That's likely to >> stay true even with cross-language LTO, because as far as the linker is >> concerned, those FFI symbols might be used by code that link against >> libxul, so it would still export them. We'd essentially need the >> equivalent to -fvisibility=hidden for Rust for that to stop being true. >> >> Mike >> >> >> > On Tue, Aug 28, 2018 at 5:17 AM, Emilio Cobos Álvarez <emi...@crisal.io> >> wrote: >> > > >> > > >> > > On 8/28/18 9:35 AM, Henri Sivonen wrote: >> > >> >> > >> Does some lld mechanism successfully remove dead code when gkrust >> > >> exports some FFI function that the rest of Gecko never ends up >> > >> calling? >> > > >> > > >> > > I would expect LTO to get rid of it, but haven't checked myself. >> > > >> > >> I.e. in terms of code size, is it OK to vendor an FFI-exposing Rust >> > >> crate where not every FFI function is used (at least right away)? >> > >> >> > > _______________________________________________ >> > > dev-platform mailing list >> > > dev-platform@lists.mozilla.org >> > > https://lists.mozilla.org/listinfo/dev-platform >> > _______________________________________________ >> > dev-platform mailing list >> > dev-platform@lists.mozilla.org >> > https://lists.mozilla.org/listinfo/dev-platform >> _______________________________________________ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform >> > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
