Hacker News Reader

Comment by haberman | Hacker News Reader

> I suppose this is the end of the dive, unless someone knows some tools to get more insight into .rodata data. I suppose in theory it should be possible to track down where in the code each bit of .rodata is accessed from, but that seems bit of a stretch.

My tool Bloaty (https://github.com/google/bloaty) attempts to do exactly this. It even disassembles the binary looking for instructions that reference other sections like .rodata.

It doesn't currently know anything about Rust's name mangling scheme. I'd be happy to add this, though I suppose Rust's mangling is probably written in Rust and Bloaty is written in C++.

View on HN

GNU libiberty includes a Rust symbol demangler that you can link: https://github.com/gcc-mirror/gcc/blob/master/libiberty/rust...

Cool. So I ran bloaty (with -d sections,segments,rawsymbols) on tinyrocket and used rustfilt[1] to demangle the symbols, and we have numbers for .rodata:

    demangled                                                   Filesize (KiB)
    idna::uts46::find_char                                            89.25
    unicode_normalization::normalize::d                               69.52
    [384 Others]                                                      43.48
    rocket::config::RocketConfig::override_from_env                   23.59
    unicode_bidi::char_data::bidi_class                               15.16
    idna::uts46::decode_slice                                         12.23
    unicode_normalization::normalize::compose                         10.29
    core::num::dec2flt::algorithm::power_of_ten                        5.97
    unicode_normalization::tables::normalization::canonical_comb       3.91
    [section .rodata]                                                  1.99
    idna::uts46::validate                                              1.95
    <hyper::status::StatusCode as core::fmt::Debug>::fmt               1.79
    tinyrocket::main                                                   1.46
    core::num::flt2dec::strategy::grisu::CACHED_POW10                  1.27
    rocket::config::config::Config::set_raw                            1.15
    time::display::parse_type                                          0.99
    hyper::server::listener::spawn_with::{{closure}}                   0.96
    percent_encoding::percent_encode_byte                              0.76
    <hyper::status::StatusCode as core::fmt::Display>::fmt             0.71
    rocket::catcher::defaults::get::handle_431                         0.66
    rocket::config::init::{{closure}}                                  0.65

Lots of unicode and idna stuff there. I think the binary size would be reduced significantly if we could drop those somehow.

Most likely those embedded HTML (error) pages are accounted in "rocket::config::RocketConfig::override_from_env", which sort of makes sense.

> It doesn't currently know anything about Rust's name mangling scheme. I'd be happy to add this, though I suppose Rust's mangling is probably written in Rust and Bloaty is written in C++.

I suppose you don't want to have a (optional) dependency to Rust code? It should be pretty easy to provide C interface to rustc-demangle[2] which would be usable from Bloaty.

[1] https://github.com/luser/rustfilt [2] https://github.com/alexcrichton/rustc-demangle

And if you are willing to depend on Rust code, there's also a C++ symbol demangler written in Rust... :)

http://fitzgeraldnick.com/2017/02/22/cpp-demangle.html

This was easier than I thought:

https://github.com/google/bloaty/compare/master...zokier:rus...

and here is the wrapper for rustc-demangle:

https://github.com/zokier/rust-demangle-clib

Seems to work just fine for my simple use at least:

    [zokier@zarch bloaty]$ ./bloaty -d sections,segments,symbols -C rust /tmp/tinyrocket/target/release/tinyrocket
         VM SIZE                                                                                        FILE SIZE
     --------------                                                                                  --------------
      52.0%   506Ki .text                                                                              506Ki  24.8%
         100.0%   506Ki LOAD [RX]                                                                          506Ki 100.0%
              65.6%   332Ki [967 Others]                                                                       332Ki  65.6%
               5.1%  25.7Ki hyper::server::listener::spawn_with::{{closure}}                                  25.7Ki   5.1%
               3.6%  18.3Ki <yansi::Paint<T> as core::fmt::Display>::fmt                                      18.3Ki   3.6%
               2.9%  14.5Ki rocket::ignite                                                                    14.5Ki   2.9%
               2.5%  12.8Ki rocket::config::config::Config::set_raw                                           12.8Ki   2.5%
               2.1%  10.7Ki core::ptr::drop_in_place                                                          10.7Ki   2.1%
               1.9%  9.78Ki std::sys_common::backtrace::output                                                9.78Ki   1.9%
               1.9%  9.62Ki tinyrocket::main                                                                  9.62Ki   1.9%
               1.6%  8.16Ki <alloc::raw_vec::RawVec<T, A>>::double                                            8.16Ki   1.6%
    ...

I can try to clean it up bit more etc if you want a proper pull request for this?

Cool! If the dependency is optional I think this would be great and I'd love to see a PR for it. It could be configured at CMake time.

I think I'd prefer to just make this part of shortsymbols/fullsymbols instead of making a separate "rustsymbols". I assume that Rust symbols won't successfully demangle as C++ (and vice-versa), so we can just try both demanglers and use whatever works. That seems like it will be more graceful for mixed C++/Rust binaries.

I created https://github.com/google/bloaty/issues/110 to track this. I'll try to find time to clean up the patch, but no promises. Lets continue the discussion in the GH issue.

That looks like a very cool tool, thanks for sharing! Bookmarked :)

Reply on news.ycombinator.com