google / bloaty Goto Github PK

Bloaty: a size profiler for binaries

License: Apache License 2.0

C++ 95.22% Shell 0.30% CMake 3.79% Python 0.69%

bloaty's Introduction

Bloaty: a size profiler for binaries

Ever wondered what's making your binary big? Bloaty will show you a size profile of the binary so you can understand what's taking up space inside.

$ ./bloaty bloaty -d compileunits
    FILE SIZE        VM SIZE    
 --------------  -------------- 
  34.8%  10.2Mi  43.4%  2.91Mi    [163 Others]
  17.2%  5.08Mi   4.3%   295Ki    third_party/protobuf/src/google/protobuf/descriptor.cc
   7.3%  2.14Mi   2.6%   179Ki    third_party/protobuf/src/google/protobuf/descriptor.pb.cc
   4.6%  1.36Mi   1.1%  78.4Ki    third_party/protobuf/src/google/protobuf/text_format.cc
   3.7%  1.10Mi   4.5%   311Ki    third_party/capstone/arch/ARM/ARMDisassembler.c
   1.3%   399Ki  15.9%  1.07Mi    third_party/capstone/arch/M68K/M68KDisassembler.c
   3.2%   980Ki   1.1%  75.3Ki    third_party/protobuf/src/google/protobuf/generated_message_reflection.cc
   3.2%   965Ki   0.6%  40.7Ki    third_party/protobuf/src/google/protobuf/descriptor_database.cc
   2.8%   854Ki  12.0%   819Ki    third_party/capstone/arch/X86/X86Mapping.c
   2.8%   846Ki   1.0%  66.4Ki    third_party/protobuf/src/google/protobuf/extension_set.cc
   2.7%   800Ki   0.6%  41.2Ki    third_party/protobuf/src/google/protobuf/generated_message_util.cc
   2.3%   709Ki   0.7%  50.7Ki    third_party/protobuf/src/google/protobuf/wire_format.cc
   2.1%   637Ki   1.7%   117Ki    third_party/demumble/third_party/libcxxabi/cxa_demangle.cpp
   1.8%   549Ki   1.7%   114Ki    src/bloaty.cc
   1.7%   503Ki   0.7%  48.1Ki    third_party/protobuf/src/google/protobuf/repeated_field.cc
   1.6%   469Ki   6.2%   427Ki    third_party/capstone/arch/X86/X86DisassemblerDecoder.c
   1.4%   434Ki   0.2%  15.9Ki    third_party/protobuf/src/google/protobuf/message.cc
   1.4%   422Ki   0.3%  23.4Ki    third_party/re2/re2/dfa.cc
   1.3%   407Ki   0.4%  24.9Ki    third_party/re2/re2/regexp.cc
   1.3%   407Ki   0.4%  29.9Ki    third_party/protobuf/src/google/protobuf/map_field.cc
   1.3%   397Ki   0.4%  24.8Ki    third_party/re2/re2/re2.cc
 100.0%  29.5Mi 100.0%  6.69Mi    TOTAL

Bloaty performs a deep analysis of the binary. Using custom ELF, DWARF, and Mach-O parsers, Bloaty aims to accurately attribute every byte of the binary to the symbol or compileunit that produced it. It will even disassemble the binary looking for references to anonymous data.

Bloaty supports many features:

file formats: ELF, Mach-O, PE/COFF (experimental), WebAssembly (experimental)
data sources: compileunit (shown above), symbol, section, segment, etc.
hierarchical profiles: combine multiple data sources into a single report
size diffs: see where the binary grew, perfect for CI tests
separate debug files: strip the binary under test, while making debug data available for analysis
flexible demangling: demangle C++ symbols, optionally discarding function/template parameters
custom data sources: regex rewrites of built-in data sources, for custom munging/bucketing
regex filtering: filter out parts of the binary that do or don't match a given regex
easy to deploy: statically-linked C++ binary, easy to copy around

For detailed info on all of Bloaty's features, see the User Documentation.

For more information about the analysis performed by Bloaty, please see How Bloaty Works.

Install

To build, use cmake. For example:

$ cmake -B build -G Ninja -S .
$ cmake --build build
$ cmake --build build --target install

Bloaty bundles libprotobuf, re2, capstone, and pkg-config as Git submodules, and uses protoc build from libprotobuf, but it will prefer the system's versions of those dependencies if available. All other dependencies are included as Git submodules.

If the Git repository hasn't been cloned with the --recursive, the submodules can be checked out with:

$ git submodule update --init --recursive

To run the tests, see the info in tests/README.md.

Support

GitHub issues and PRs welcome. Please include tests when possible, see: tests/README.md.

This is not an official Google product.

bloaty's People

Contributors

Stargazers

Watchers

Forkers

safarmer arthurhsliu dascandy stewmh emaste vovoid krupatil mkurdej gela brookst binioter shahzadmajeed 646k wdv4758h velisa phomes pchx-zz claudiouzelac chenyming rm3l etheaven bschindler sievlev imtorgopendatatools pombredanne wjt hbcbh1999 cwgreene 4144 zliuva 3herkd kernux msabramo gophersgang dtzwill alexxnica multi-os-engine duzhanyuan charlie-ht zbsz asheemmamoowala haberman carlhuth nelhage nelhage-stripe jonathanmarvens vincentlao qzmfranklin kevinneu deeptechlabs devenlu brianwitte fjh658 md-command-line zhouhanqing amahagaonkar zokier andrewlixin jakehehrlich leiradel psteinb taozhang8 wyyangx voldemur afeindsc timonvo gubaojian roffjulie kernullist yanana bavery22 caiiiycuk ericwomer kjlubick deepankarsharma morya swills exhorder cabin33 kent08ian yazici justinzjz acidburn0zzz auscanaoy keir huijielin tiwalun bj-lee90 colinianking psmarshall xingheandu wang-bin ajdavis adamj-codethink gongcm gaintpd rlinks234 frolv max19931 swolchok

bloaty's Issues

What is [Unmapped] when using symbols/cppsymbols?

A large chunk of my binary is [Unmapped] when using cppsymbols, how do I dig further into that?

No good way to add test cases.

make_tests_files.sh after running will result in the binaries being different, which makes it unsuitable for reproducing the test cases (and also means that new test cases cannot be verified easily; but trust me, I'm sure all the binary blobs that I will commit to this repo can be trusted ;) ). Arguably, only make_test_files.sh should be committed, and have the test cases get automatically regenerated. This has the obvious drawback of not having a canonical test cases (and requiring careful control over compiler versions).¹

Ideas?

¹ More seriously, it basically means that at the very least, one would have to add cross compilers to the toolchain.

-d compileunits does not work with Go programs

$ cat main.go 
package main

import "fmt"

func main() {
	fmt.Println("vim-go")
}

$ go build

$ ../bloaty/bloaty ./main
     VM SIZE                       FILE SIZE
 --------------                 --------------
  44.1%   492Ki .text             492Ki  30.9%
  24.1%   269Ki .gopclntab        269Ki  16.9%
   0.0%       0 .debug_info       240Ki  15.0%
  18.5%   207Ki .rodata           207Ki  13.0%
   9.5%   106Ki .bss                  0   0.0%
   0.0%       0 .debug_line      98.4Ki   6.2%
   0.0%       0 .debug_frame     66.9Ki   4.2%
   0.0%       0 .debug_pubnames  60.5Ki   3.8%
   0.0%       0 .strtab          51.9Ki   3.3%
   0.0%       0 .symtab          51.6Ki   3.2%
   0.0%       0 .debug_pubtypes  26.8Ki   1.7%
   1.8%  19.6Ki .noptrbss             0   0.0%
   0.2%  2.37Ki [Unmapped]       9.47Ki   0.6%
   0.7%  8.07Ki .noptrdata       8.07Ki   0.5%
   0.7%  7.36Ki .data            7.36Ki   0.5%
   0.2%  2.74Ki .typelink        2.74Ki   0.2%
   0.2%  1.88Ki [ELF Headers]    1.88Ki   0.1%
   0.0%       0 .shstrtab           257   0.0%
   0.0%       0 .debug_abbrev       255   0.0%
   0.0%     120 [Other]             211   0.0%
   0.0%      16 [None]                0   0.0%
 100.0%  1.09Mi TOTAL            1.56Mi 100.0%

$ ../bloaty/bloaty ./main -d compileunits
bloaty: internal error, specified same DWARF attribute more than once

This is bloaty commit 83fe66b on 64bit Linux.

'Segmentation fault' issue found with AFL

As discussed through an internal channel, I have been doing fuzzing with AFL and I will file issues on GitHub.

Here is an out-of-bound memcpy().

Call stack:

#0  0x00000000004142d3 in memcpy (__len=64, __src=0x7ffff7ff4fff, 
    __dest=0x7fffffffd0e8) at /usr/include/x86_64-linux-gnu/bits/string3.h:53
#1  bloaty::(anonymous namespace)::ElfFile::StructReader::Memcpy<Elf64_Shdr> (
    out=0x7fffffffd0e8, offset=18446744073709551615, this=<optimized out>)
    at src/elf.cc:148
#2  bloaty::(anonymous namespace)::ElfFile::StructReader::Read<Elf32_Shdr, Elf64_Shdr, bloaty::(anonymous namespace)::ShdrMunger> (out=0x7fffffffd0e8, 
    offset=<optimized out>, this=<optimized out>, munger=...) at src/elf.cc:132
#3  bloaty::(anonymous namespace)::ElfFile::ReadStruct<Elf32_Shdr, Elf64_Shdr, bloaty::(anonymous namespace)::ShdrMunger> (out=0x7fffffffd0e8, 
    offset=<optimized out>, this=0x7fffffffd1d0, munger=...) at src/elf.cc:155
#4  bloaty::(anonymous namespace)::ElfFile::ReadSection (this=0x7fffffffd1d0, 
    index=<optimized out>, section=0x7fffffffd0e0) at src/elf.cc:378
#5  0x0000000000414725 in bloaty::(anonymous namespace)::ElfFile::Initialize (
    this=this@entry=0x7fffffffd1d0) at src/elf.cc:339
#6  0x0000000000416b06 in bloaty::(anonymous namespace)::ElfFile::ElfFile (
    data=..., this=0x7fffffffd1d0) at src/elf.cc:58
#7  bloaty::TryOpenELFFile (file=...) at src/elf.cc:894
#8  0x000000000040d6cd in bloaty::Bloaty::ScanAndRollupFile (
---Type <return> to continue, or q <return> to quit--- 
    fffffffd780, file=..., rollup=rollup@entry=0x7fffffffd640) at src/bloaty.cc:1389
#9  0x000000000040ef8a in bloaty::Bloaty::ScanAndRollup (this=this@entry=0x7fffffffd780, 
    output=output@entry=0x7fffffffda00) at src/bloaty.cc:1513
#10 0x000000000040f97e in bloaty::BloatyMain (argc=argc@entry=2, argv=argv@entry=0x7fffffffdb98, 
    file_factory=..., output=output@entry=0x7fffffffda00) at src/bloaty.cc:1659
#11 0x0000000000403a65 in main (argc=2, argv=0x7fffffffdb98) at src/main.cc:22

Minimal repro case:

$ xxd input.minimized 
00000000: 7f45 4c46 0201 3030 3030 3030 3030 3030  .ELF..0000000000
00000010: 3030 3030 3030 3030 3030 3030 3030 3030  0000000000000000
00000020: 3030 3030 3030 3030 ffff ffff ffff ffff  00000000........
00000030: 3030 3030 3030 3030 3030 3000 3030 3030  00000000000.0000

$ base64 input.minimized 
f0VMRgIBMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMP//////////MDAwMDAwMDAwMDAAMDAwMA==

Improper shell out to program 'symbols' after failing to process MachO file

On Linux:

$ ./bloaty ~/bloaty -d symbols
sh: 1: otool: not found
sh: 1: symbols: not found
     VM SIZE              FILE SIZE
 --------------        --------------
  -NAN%       0 [None]   644Ki 100.0%
 100.0%       0 TOTAL    644Ki 100.0%

When a non-MachO binary is supplied, no shell errors occur, and symbols are displayed.

Debugging stripped MachO binaries?

As far as I can tell, the README section "Debugging Stripped Binaries" applies only to ELF binaries. MachO does not seem to have an equivalent to .note.gnu.build-id, and Apple's ld errors if given a --build-id option.

Is there any other way to get meaningful bloaty output from a stripped MachO binary + .dSYM pair? Using an unstripped binary is problematic; I've seen a String Table section occupying almost 50% of the unstripped binary size, skewing the output.

(A minor quirk of what is otherwise an invaluable tool. Thanks for continuing to work on bloaty; it seems to have gotten better and better each time I find myself using it!)

Using -n 0 doesn't work contrary to help

bloaty --help includes the following:

  -n <num>         How many rows to show per level before collapsing
                   other keys into '[Other]'.  Set to '0' for unlimited.
                   Defaults to 20.

However, the simple command bloaty -n 0 some_binary reports:

bloaty: max_rows_per_level must be at least 1

"missing debug info" for executable with compressed debug sections

Nice work! Bloaty looks useful. I notice it complains about missing debug sections if the debug section is compressed, e.g.:

$ cat > test.cpp
int main() { }
$ g++ test.cpp -gdwarf -Wl,-fuse-ld=gold -Wl,--compress-debug-sections=zlib
$ ./bloaty ./a.out -d compileunits                                         
bloaty: missing debug info
$ ./bloaty ./a.out
     VM SIZE                       FILE SIZE
 --------------                 --------------
  20.8%     512 [ELF Headers]    2.75Ki  39.7%
   0.0%       0 .symtab             912  12.8%
   0.0%       0 .strtab             550   7.7%
  20.8%     512 .dynamic            512   7.2%
   0.0%       0 .shstrtab           413   5.8%
  16.6%     407 .text               407   5.7%
   9.6%     237 [Other]             271   3.8%
   9.9%     244 .eh_frame           244   3.4%
   6.9%     169 .dynstr             169   2.4%
   5.9%     144 .dynsym             144   2.0%
   0.0%       0 .zdebug_str         108   1.5%
   0.0%       0 .comment             79   1.1%
   0.0%       0 .zdebug_abbrev       73   1.0%
   0.0%       0 .zdebug_info         67   0.9%
   0.0%       0 .zdebug_line         64   0.9%
   2.1%      52 .eh_frame_hdr        52   0.7%
   2.0%      48 .plt                 48   0.7%
   2.0%      48 .rela.plt            48   0.7%
   1.8%      44 .hash                44   0.6%
   1.6%      40 .got.plt             40   0.6%
   0.0%       0 .zdebug_aranges      40   0.6%
 100.0%  2.40Ki TOTAL            6.93Ki 100.0%

It should either use the compressed debug section, or display a message that it cannot read compressed debug sections.

Assertion `index < section_count_' failed.

The problem occurs on very simple (i.e., non-GCC) ELF executables such as those produced by FASM.

[def@arch bloaty]% cat hello.asm 
; fasm demonstration of writing simple ELF executable

format ELF executable 3
entry start

segment readable executable

start:

	mov	eax,4
	mov	ebx,1
	mov	ecx,msg
	mov	edx,msg_size
	int	0x80

	mov	eax,1
	xor	ebx,ebx
	int	0x80

segment readable writeable

msg db 'Hello world!',0xA
msg_size = $-msg
[def@arch bloaty]% fasm hello.asm 
flat assembler  version 1.71.57  (16384 kilobytes memory)
3 passes, 160 bytes.
[def@arch bloaty]% ./hello
Hello world!
[def@arch bloaty]% ./bloaty hello
bloaty: src/elf.cc:359: bool bloaty::{anonymous}::ElfFile::ReadSection(Elf64_Word, bloaty::{anonymous}::ElfFile::Section*) const: Assertion `index < section_count_' failed.
zsh: abort (core dumped)  ./bloaty hello

Download link for the binary: hello

bloaty: VM range (0, 4) for label state_fd.6026 extends beyond base map

I get the subject line error when I try to run on my binary:

./bloaty mybinary -d compileunits

running without -d works fine. the binary was compiled with gcc7 with debug information enabled (-g).

unfortunately can't link the source, but happy to post output from any diagnostic commands that might be helpful.

-d inlines doesn't work

~ % echo "int main(){}" | g++ -g -x c++ - && bloaty -d inlines ./a.out
bloaty: internal error, specified same DWARF attribute more than once

-d compileunits on go binary shows suspiciously large size for sync/atomic

I ran bloaty on an internal go binary which reported sync/atomic using ~30% of the binary size. This seemed... unlikely. So I tried running bloatly on an etcd binary (linux amd64) compiled from master which shows something very similar:

$ /tmp/bloaty/bloaty -d compileunits etcd -n 5
     VM SIZE                              FILE SIZE
 --------------                        --------------
  49.0%  2.92Mi [142 Others]            4.27Mi  46.2%
  30.8%  1.83Mi sync/atomic             2.79Mi  30.2%
   9.1%   557Ki net/http                 824Ki   8.7%
   7.3%   444Ki runtime                  733Ki   7.8%
   3.8%   234Ki net                      345Ki   3.7%
   0.0%       0 [section .debug_frame]   329Ki   3.5%
 100.0%  5.96Mi TOTAL                   9.23Mi 100.0%

30% doesn't sound right to me as sync/atomic is a small amount of assembly code and not much else.

I'm hoping someone could shed some light onto what is going on here. Is this somehow related to inlining?

add structured (JSON/XML) output

... so one can post-process the results using scripts/tools. Parsing text results is suboptimal.

Even just disabling the use of abbreviations (e.g. 8.31Ki) via an option would help tremendously.

When this is possible one can create a visual output similar to this:

Build fails on Devuan Ascii

I am getting following errors when built on Devuan Ascii.
Any help?

Scanning dependencies of target bloaty
Scanning dependencies of target bloaty_test
Scanning dependencies of target bloaty_misc_test
Scanning dependencies of target fuzz_test
Scanning dependencies of target range_map_test
[ 98%] Building CXX object CMakeFiles/bloaty.dir/src/main.cc.o
[ 98%] Building CXX object CMakeFiles/bloaty_misc_test.dir/tests/bloaty_misc_test.cc.o
[ 98%] Building CXX object CMakeFiles/bloaty_test.dir/tests/bloaty_test.cc.o
[ 98%] Building CXX object CMakeFiles/fuzz_test.dir/tests/fuzz_target.cc.o
[ 99%] Building CXX object CMakeFiles/fuzz_test.dir/tests/fuzz_driver.cc.o
[ 99%] Building CXX object CMakeFiles/range_map_test.dir/tests/range_map_test.cc.o
[ 99%] Linking CXX executable bloaty
[ 99%] Linking CXX executable fuzz_test
/usr/bin/ld: third_party/capstone/libcapstone.a(cs.c.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: third_party/capstone/libcapstone.a(SStream.c.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: third_party/capstone/libcapstone.a(ARMModule.c.o): relocation R_X86_64_32 against symbol `Thumb_getInstruction' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: third_party/capstone/libcapstone.a(AArch64Module.c.o): relocation R_X86_64_32S against symbol `AArch64_printInst' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: third_party/capstone/libcapstone.a(MipsModule.c.o): relocation R_X86_64_32S against symbol `Mips_printInst' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: third_party/capstone/libcapstone.a(PPCModule.c.o): relocation R_X86_64_32S against symbol `PPC_printInst' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: third_party/capstone/libcapstone.a(X86Module.c.o): relocation R_X86_64_32 against symbol `regsize_map_64' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: third_party/capstone/libcapstone.a(X86ATTInstPrinter.c.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: third_party/capstone/libcapstone.a(SparcModule.c.o): relocation R_X86_64_32S against symbol `Sparc_printInst' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: third_party/capstone/libcapstone.a(SystemZModule.c.o): relocation R_X86_64_32S against symbol `SystemZ_printInst' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: third_party/capstone/libcapstone.a(XCoreModule.c.o): relocation R_X86_64_32S against symbol `XCore_printInst' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: third_party/capstone/libcapstone.a(ARMDisassembler.c.o): relocation R_X86_64_32S against `.rodata' can not be used when making a PIE object; recompile with -fPIC

Adding following to third_party/capstone/CMakeLists.txt seems to fix the issue.

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 66127c4e..18de9166 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -5,6 +5,8 @@ set(VERSION_MAJOR 3)
 set(VERSION_MINOR 0)
 set(VERSION_PATCH 5)
 
+set(CMAKE_POSITION_INDEPENDENT_CODE ON)
+
 # to configure the options specify them in in the command line or change them in the cmake UI.
 # Don't edit the makefile!
 option(CAPSTONE_BUILD_STATIC_RUNTIME "Embed static runtime" OFF)

Demangler can't demangle some symbols

Over in mapbox-gl-native, we're using among others this symbol:

_ZZN3jni17NativeMethodMakerIMZNS_30NativePeerMemberFunctionMethodIMN4mbgl7android9LineLayerEFvR7_JNIEnvxxEXadL_ZNS4_26setLineTranslateTransitionES6_xxEEEclIS4_S4_vEEDaRKNS_5FieldIT0_xEEEUlS6_NS_6ObjectIS4_EExxE_KFvS6_SI_xxEJEEclISJ_EESB_PKcRKT_E6method

Unfortunately, the demangler included in bloaty can't demangle this symbol, so it can't aggregate them with similar symbols. c++filt can't demangle it either, but http://demangler.com can.

Idea for visualizing size

The tools/binary_size/supersize tool from chromium can produce things like this:

https://agrieve.github.io/chrome/supersize-chrome-android-oct-19-2017/

Something like that would be very useful!

bloaty crashes on iOS binary with 32-bit slice

$ ~/bloaty/build/bloaty -d segments,symbols ~/DerivedData/Sample32BitApp-bidyzjauapexirbbisbrcviudqcb/Build/Products/Debug-iphoneos/Sample32BitApp.app/Sample32BitApp
libc++abi.dylib: terminating with uncaught exception of type std::out_of_range: absl::string_view::substr

Backtrace:

(lldb) bt all
* thread #1, stop reason = signal SIGSTOP
  * frame #0: 0x00007fff54f8e05a libsystem_kernel.dylib`__semwait_signal + 10
    frame #1: 0x00007fff550cd8ec libsystem_pthread.dylib`_pthread_join + 626
    frame #2: 0x00007fff52eb4828 libc++.1.dylib`std::__1::thread::join() + 24
    frame #3: 0x000000010cddda9f bloaty`bloaty::Bloaty::ScanAndRollupFiles(std::__1::vector<std::__1::unique_ptr<bloaty::ObjectFile, std::__1::default_delete<bloaty::ObjectFile> >, std::__1::allocator<std::__1::unique_ptr<bloaty::ObjectFile, std::__1::default_delete<bloaty::ObjectFile> > > > const&, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >*, bloaty::Rollup*) const + 911
    frame #4: 0x000000010cddedb7 bloaty`bloaty::Bloaty::ScanAndRollup(bloaty::Options const&, bloaty::RollupOutput*) + 951
    frame #5: 0x000000010cde6b3e bloaty`bloaty::BloatyDoMain(bloaty::Options const&, bloaty::InputFileFactory const&, bloaty::RollupOutput*) + 1566
    frame #6: 0x000000010cde6f49 bloaty`bloaty::BloatyMain(bloaty::Options const&, bloaty::InputFileFactory const&, bloaty::RollupOutput*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*) + 41
    frame #7: 0x000000010cdbef55 bloaty`main + 1125
    frame #8: 0x00007fff54e3e115 libdyld.dylib`start + 1
  thread #2, stop reason = signal SIGSTOP
    frame #0: 0x00007fff54f8de3e libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff550cc150 libsystem_pthread.dylib`pthread_kill + 333
    frame #2: 0x00007fff54eea312 libsystem_c.dylib`abort + 127
    frame #3: 0x00007fff52ec5f8f libc++abi.dylib`abort_message + 245
    frame #4: 0x00007fff52ec6113 libc++abi.dylib`default_terminate_handler() + 241
    frame #5: 0x00007fff54250eab libobjc.A.dylib`_objc_terminate() + 105
    frame #6: 0x00007fff52ee17c9 libc++abi.dylib`std::__terminate(void (*)()) + 8
    frame #7: 0x00007fff52ee126d libc++abi.dylib`__cxa_throw + 121
    frame #8: 0x000000010ce8c54b bloaty`void absl::base_internal::(anonymous namespace)::Throw<std::out_of_range>(std::out_of_range const&) + 75
    frame #9: 0x000000010ce8c5af bloaty`absl::base_internal::ThrowStdOutOfRange(char const*) + 95
    frame #10: 0x000000010cdd4539 bloaty`absl::string_view::substr(unsigned long, unsigned long) const + 57
    frame #11: 0x000000010ce7d88e bloaty`bloaty::macho::ParseSymbolsFromSymbolTable(absl::string_view, absl::string_view, bloaty::RangeSink*) + 334
    frame #12: 0x000000010ce82b30 bloaty`bloaty::macho::ParseSymbols(bloaty::RangeSink*)::$_1::operator()(unsigned int, absl::string_view, absl::string_view) const + 144
    frame #13: 0x000000010ce827fd bloaty`void bloaty::macho::ParseMachOHeaderImpl<mach_header, bloaty::macho::ParseSymbols(bloaty::RangeSink*)::$_1>(absl::string_view, bloaty::RangeSink*, bloaty::macho::ParseSymbols(bloaty::RangeSink*)::$_1&&) + 381
    frame #14: 0x000000010ce82479 bloaty`void bloaty::macho::ParseMachOHeader<bloaty::macho::ParseSymbols(bloaty::RangeSink*)::$_1>(absl::string_view, bloaty::RangeSink*, bloaty::macho::ParseSymbols(bloaty::RangeSink*)::$_1&&) + 201
    frame #15: 0x000000010ce7dbec bloaty`void bloaty::macho::ForEachLoadCommand<bloaty::macho::ParseSymbols(bloaty::RangeSink*)::$_1>(absl::string_view, bloaty::RangeSink*, bloaty::macho::ParseSymbols(bloaty::RangeSink*)::$_1&&) + 204
    frame #16: 0x000000010ce7db12 bloaty`bloaty::macho::ParseSymbols(bloaty::RangeSink*) + 66
    frame #17: 0x000000010ce7eaee bloaty`bloaty::macho::MachOObjectFile::ProcessFile(std::__1::vector<bloaty::RangeSink*, std::__1::allocator<bloaty::RangeSink*> > const&) const + 510
    frame #18: 0x000000010cddaf78 bloaty`bloaty::Bloaty::ScanAndRollupFile(bloaty::ObjectFile*, bloaty::Rollup*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*) const + 8008
    frame #19: 0x000000010ce1c36f bloaty`bloaty::Bloaty::ScanAndRollupFiles(std::__1::vector<std::__1::unique_ptr<bloaty::ObjectFile, std::__1::default_delete<bloaty::ObjectFile> >, std::__1::allocator<std::__1::unique_ptr<bloaty::ObjectFile, std::__1::default_delete<bloaty::ObjectFile> > > > const&, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >*, bloaty::Rollup*) const::$_6::operator()(bloaty::Bloaty::ScanAndRollupFiles(std::__1::vector<std::__1::unique_ptr<bloaty::ObjectFile, std::__1::default_delete<bloaty::ObjectFile> >, std::__1::allocator<std::__1::unique_ptr<bloaty::ObjectFile, std::__1::default_delete<bloaty::ObjectFile> > > > const&, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >*, bloaty::Rollup*) const::PerThreadData*) const + 191
    frame #20: 0x000000010ce1c01e bloaty`void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, bloaty::Bloaty::ScanAndRollupFiles(std::__1::vector<std::__1::unique_ptr<bloaty::ObjectFile, std::__1::default_delete<bloaty::ObjectFile> >, std::__1::allocator<std::__1::unique_ptr<bloaty::ObjectFile, std::__1::default_delete<bloaty::ObjectFile> > > > const&, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >*, bloaty::Rollup*) const::$_6, bloaty::Bloaty::ScanAndRollupFiles(std::__1::vector<std::__1::unique_ptr<bloaty::ObjectFile, std::__1::default_delete<bloaty::ObjectFile> >, std::__1::allocator<std::__1::unique_ptr<bloaty::ObjectFile, std::__1::default_delete<bloaty::ObjectFile> > > > const&, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >*, bloaty::Rollup*) const::PerThreadData*> >(void*) + 574
    frame #21: 0x00007fff550c96c1 libsystem_pthread.dylib`_pthread_body + 340
    frame #22: 0x00007fff550c956d libsystem_pthread.dylib`_pthread_start + 377
    frame #23: 0x00007fff550c8c5d libsystem_pthread.dylib`thread_start + 13

Disabling 32-bit Mach-O parsing by commenting out https://github.com/google/bloaty/blob/master/src/macho.cc#L156 allows bloaty to run without crashing, which is useful for fat iOS binaries.

Demangling of C++ names of Linux Binaries does not work on Mac OS

Steps to reproduce:

Compare output of tests/testdata/linux-x86_64/oldbloaty.bin on Linux and Mac.

Linux:

     VM SIZE                                                                                        FILE SIZE
 --------------                                                                                  --------------
  20.0%  99.0Ki [Unmapped]                                                                        6.55Mi  94.4%
  62.1%   307Ki [Other]                                                                            308Ki   4.3%
   2.5%  12.3Ki re2::RE2::Match(re2::StringPiece const&, int, int, re2::RE2::Anchor, re2::String  12.3Ki   0.2%
   1.6%  7.83Ki re2::unicode_groups                                                               7.83Ki   0.1%
   1.5%  7.56Ki re2::NFA::Search                                                                  7.56Ki   0.1%
   1.2%  5.76Ki re2::BitState::TrySearch                                                          5.76Ki   0.1%
   1.0%  4.81Ki _dwarf_exec_frame_instr                                                           4.81Ki   0.1%
   0.9%  4.49Ki re2::DFA::DFA                                                                     4.49Ki   0.1%
   0.9%  4.34Ki re2::Regexp::Parse                                                                4.34Ki   0.1%
   0.8%  4.20Ki re2::RE2::Init                                                                    4.20Ki   0.1%
   0.8%  4.09Ki re2::Prog::IsOnePass                                                              4.09Ki   0.1%
   0.8%  4.04Ki re2::Compiler::PostVisit                                                          4.04Ki   0.1%
   0.8%  4.01Ki _dwarf_internal_srclines                                                          4.01Ki   0.1%
   0.8%  3.91Ki re2::Regexp::FactorAlternationRecursive                                           3.91Ki   0.1%
   0.8%  3.86Ki bool bloaty::(anonymous namespace)::ForEachElf<bloaty::(anonymous namespace)::Do  3.86Ki   0.1%
   0.8%  3.77Ki re2::DFA::RunStateOnByte                                                          3.77Ki   0.1%
   0.7%  3.68Ki re2::unicode_casefold                                                             3.68Ki   0.1%
   0.7%  3.40Ki re2::DFA::InlinedSearchLoop(re2::DFA::SearchParams*, bool, bool, bool) [clone .c  3.40Ki   0.0%
   0.7%  3.38Ki re2::DFA::InlinedSearchLoop(re2::DFA::SearchParams*, bool, bool, bool) [clone .c  3.38Ki   0.0%
   0.7%  3.35Ki re2::Regexp::Walker<int>::WalkInternal(re2::Regexp*, int, bool) [clone .constpro  3.35Ki   0.0%
   0.0%     165 [None]                                                                                 0   0.0%
 100.0%   495Ki TOTAL                                                                             6.93Mi 100.0%

Mac:

     VM SIZE                                                                                        FILE SIZE
 --------------                                                                                  --------------
  20.0%  99.0Ki [Unmapped]                                                                        6.55Mi  94.4%
  62.1%   307Ki [Other]                                                                            308Ki   4.3%
   2.5%  12.3Ki _ZNK3re23RE25MatchERKNS_11StringPieceEiiNS0_6AnchorEPS1_i                         12.3Ki   0.2%
   1.6%  7.83Ki _ZN3re214unicode_groupsE                                                          7.83Ki   0.1%
   1.5%  7.56Ki _ZN3re23NFA6SearchERKNS_11StringPieceES3_bbPS1_i                                  7.56Ki   0.1%
   1.2%  5.76Ki _ZN3re28BitState9TrySearchEiPKc                                                   5.76Ki   0.1%
   1.0%  4.81Ki _dwarf_exec_frame_instr                                                           4.81Ki   0.1%
   0.9%  4.49Ki _ZN3re23DFAC1EPNS_4ProgENS1_9MatchKindEl                                          4.49Ki   0.1%
   0.9%  4.34Ki _ZN3re26Regexp5ParseERKNS_11StringPieceENS0_10ParseFlagsEPNS_12RegexpStatusE      4.34Ki   0.1%
   0.8%  4.20Ki _ZN3re23RE24InitERKNS_11StringPieceERKNS0_7OptionsE                               4.20Ki   0.1%
   0.8%  4.09Ki _ZN3re24Prog9IsOnePassEv                                                          4.09Ki   0.1%
   0.8%  4.04Ki _ZN3re28Compiler9PostVisitEPNS_6RegexpENS_4FragES3_PS3_i                          4.04Ki   0.1%
   0.8%  4.01Ki _dwarf_internal_srclines                                                          4.01Ki   0.1%
   0.8%  3.91Ki _ZN3re26Regexp26FactorAlternationRecursiveEPPS0_iNS0_10ParseFlagsEi               3.91Ki   0.1%
   0.8%  3.86Ki _ZN6bloaty12_GLOBAL__N_110ForEachElfIZNS0_L17DoReadELFSectionsEPNS_9RangeSinkEbE  3.86Ki   0.1%
   0.8%  3.77Ki _ZN3re23DFA14RunStateOnByteEPNS0_5StateEi                                         3.77Ki   0.1%
   0.7%  3.68Ki _ZN3re216unicode_casefoldE                                                        3.68Ki   0.1%
   0.7%  3.40Ki _ZN3re23DFA17InlinedSearchLoopEPNS0_12SearchParamsEbbb.constprop.134              3.40Ki   0.0%
   0.7%  3.38Ki _ZN3re23DFA17InlinedSearchLoopEPNS0_12SearchParamsEbbb.constprop.133              3.38Ki   0.0%
   0.7%  3.35Ki _ZN3re26Regexp6WalkerIiE12WalkInternalEPS0_ib.constprop.183                       3.35Ki   0.0%
   0.0%     165 [None]                                                                                 0   0.0%
 100.0%   495Ki TOTAL                                                                             6.93Mi 100.0%

Note that mac binaries built on mac are unaffected.

Mac binaries (MachO) on linux, of course, can't be processed because bloaty uses otool to process MachO binaries.

Assertion `state_ == State::kReadyToReadAttributes` failed.

Running bloaty on a binary (the result of ./mach build -d from https://github.com/servo/servo/) which previously hit #13 now shows:

jdm@nightblogger:~/bloaty$ ./bloaty -d inlines ../servo/target/debug/servo 
bloaty: src/dwarf.cc:515: bloaty::StringPiece bloaty::dwarf::DIEReader::ReadAttributesBegin(): Assertion `state_ == State::kReadyToReadAttributes' failed.
Aborted (core dumped)

Doesn't build on ubuntu 18.04

cmake fails in the configuration:
➜ bloaty-master cmake .
-- The C compiler identification is GNU 7.3.0
-- The CXX compiler identification is GNU 7.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Setting build type to 'RelWithDebInfo' as none was specified.
fatal: not a git repository (or any of the parent directories): .git
CMake Warning (dev) at CMakeLists.txt:29 (add_subdirectory):
The source directory
/home/yesser/Desktop/bloaty-master/third_party/re2
does not contain a CMakeLists.txt file.

CMake does not support this case but it used to work accidentally and is
being allowed for compatibility.

Policy CMP0014 is not set: Input directories must have CMakeLists.txt. Run
"cmake --help-policy CMP0014" for policy details. Use the cmake_policy
command to set the policy and suppress this warning.
This warning is for project developers. Use -Wno-dev to suppress it.

CMake Warning (dev) at CMakeLists.txt:30 (add_subdirectory):
The source directory

/home/yesser/Desktop/bloaty-master/third_party/capstone

does not contain a CMakeLists.txt file.

CMake does not support this case but it used to work accidentally and is
being allowed for compatibility.

CMake Error at CMakeLists.txt:31 (add_subdirectory):
add_subdirectory given source "third_party/protobuf/cmake" which is not an
existing directory.

-- Performing Test SUPPORTS_COLOR_ALWAYS
-- Performing Test SUPPORTS_COLOR_ALWAYS - Success
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Configuring incomplete, errors occurred!
See also "/home/yesser/Desktop/bloaty-master/CMakeFiles/CMakeOutput.log".
See also "/home/yesser/Desktop/bloaty-master/CMakeFiles/CMakeError.log".

CMakeOutput.log

Continue on "cant find file" error

Running Bloaty on a large list of object files and then having one object file that wast found stop the progression of the entire run is important, but sometimes no necessary. A continuation flag to let Bloaty know to progress on if it runs into a file it couldn't find/parse/read would be great. This would produce an inaccurate analysis of the total object sizes but with massive projects, this could be workable.

Long file names and symbols get cut off

Eg.

jdm@nightblogger:~/bloaty$ ./bloaty -d compileunits ../servo/target/debug/servo 
     VM SIZE                                                                                        FILE SIZE
 --------------                                                                                  --------------
  90.8%   109Mi [None]                                                                             462Mi  97.7%
   5.6%  6.72Mi [Other]                                                                           6.72Mi   1.4%
   0.3%   355Ki /home/jdm/servo/target/debug/build/mozjs_sys-661d4efe7c7ca939/out/js/src/Unified   355Ki   0.1%
   0.3%   346Ki /home/jdm/servo/target/debug/build/mozjs_sys-661d4efe7c7ca939/out/js/src/Unified   346Ki   0.1%
   0.3%   316Ki /home/jdm/servo/target/debug/build/mozjs_sys-661d4efe7c7ca939/out/js/src/Unified   316Ki   0.1%
   0.2%   303Ki /home/jdm/servo/target/debug/build/mozjs_sys-661d4efe7c7ca939/out/js/src/Unified   303Ki   0.1%
   0.2%   285Ki /home/jdm/servo/target/debug/build/mozjs_sys-661d4efe7c7ca939/out/js/src/Unified   285Ki   0.1%
   0.2%   265Ki /home/jdm/servo/target/debug/build/mozjs_sys-661d4efe7c7ca939/out/js/src/Unified   265Ki   0.1%
   0.2%   265Ki /home/jdm/servo/target/debug/build/mozjs_sys-661d4efe7c7ca939/out/js/src/Unified   264Ki   0.1%
   0.2%   258Ki /home/jdm/servo/target/debug/build/mozjs_sys-661d4efe7c7ca939/out/js/src/Unified   258Ki   0.1%
   0.2%   257Ki /home/jdm/servo/target/debug/build/mozjs_sys-661d4efe7c7ca939/out/js/src/Unified   257Ki   0.1%
   0.2%   253Ki /home/jdm/servo/target/debug/build/mozjs_sys-661d4efe7c7ca939/out/js/src/Unified   253Ki   0.1%
   0.2%   221Ki /home/jdm/servo/target/debug/build/mozjs_sys-661d4efe7c7ca939/out/js/src/Unified   221Ki   0.0%
   0.2%   209Ki /home/jdm/servo/target/debug/build/mozjs_sys-661d4efe7c7ca939/out/js/src/Unified   209Ki   0.0%
   0.2%   204Ki /home/jdm/servo/target/debug/build/mozjs_sys-661d4efe7c7ca939/out/js/src/Unified   204Ki   0.0%
   0.1%   170Ki /home/jdm/servo/target/debug/build/mozjs_sys-661d4efe7c7ca939/out/js/src/Unified   170Ki   0.0%
   0.1%   163Ki /home/jdm/servo/.cargo/git/checkouts/mozjs-fa11ffc7d4f1cc2d/master/mozjs/js/src/   163Ki   0.0%
   0.1%   160Ki /home/jdm/servo/target/debug/build/mozjs_sys-661d4efe7c7ca939/out/js/src/Unified   160Ki   0.0%
   0.1%   147Ki /home/jdm/servo/target/debug/build/mozjs_sys-661d4efe7c7ca939/out/js/src/Unified   147Ki   0.0%
   0.1%   146Ki /home/jdm/servo/target/debug/build/mozjs_sys-661d4efe7c7ca939/out/js/src/Unified   146Ki   0.0%
   0.1%   146Ki /home/jdm/servo/target/debug/build/mozjs_sys-661d4efe7c7ca939/out/js/src/Unified   146Ki   0.0%
 100.0%   120Mi TOTAL                                                                              473Mi 100.0%

This makes the output less useful than it could be ;)

Compile fails due to undefined `UINT64_MAX`

On my system (Linux/x86_84 and gcc 4.7.2), make fails with:

src/bloaty.h: In member function ‘bool bloaty::RangeMap::Entry::HasTranslation() const’:
src/bloaty.h:294:57: error: ‘UINT64_MAX’ was not declared in this scope

Adding #define __STDC_LIMIT_MACROS before the #include <stdint.h> in bloaty.h fixes the problem.

DWARF data is too new for us

I have a binary which has a mixture of compilation unit versions (2, 3, and 4). bloaty seems to only support up to 2 and will not partial process the binary if it has a mixture.

Any idea on when support for versions greater than 2 will happen?

Make configure option to support system packages rather than submodules

Hello.

I really like the package but as it is it's not feasible for distribution. Can you please make it using system packages?

bloaty: Unexpected eh_frame format value: 8

I tried build my binary with g++ and clang++, and analyze with bloaty. I always had same error

bloaty: Unexpected eh_frame format value: 8

I trying to analyze elf file (linux build), when I run bloaty without flags it prints correct output:

     VM SIZE                         FILE SIZE
 --------------                   --------------
   0.0%       0 .debug_info        63.3Mi  73.2%
   0.0%       0 .debug_str         5.82Mi   6.7%
   0.0%       0 .debug_loc         5.06Mi   5.8%
   0.0%       0 .debug_line        3.11Mi   3.6%
  65.1%  3.09Mi .text              3.09Mi   3.6%
   0.0%       0 .debug_abbrev      1.71Mi   2.0%
   0.0%       0 .debug_ranges      1.51Mi   1.7%
   0.0%       0 .strtab             887Ki   1.0%
  17.5%   848Ki .eh_frame           848Ki   1.0%
  13.7%   664Ki .rodata             664Ki   0.7%
   0.0%       0 .symtab             340Ki   0.4%
   1.8%  86.9Ki .eh_frame_hdr      86.9Ki   0.1%
   0.0%       0 .debug_aranges     77.0Ki   0.1%
   1.0%  50.6Ki .gcc_except_table  50.6Ki   0.1%
   0.5%  25.0Ki .bss                    0   0.0%
   0.1%  6.73Ki .dynstr            6.73Ki   0.0%
   0.1%  4.50Ki [22 Others]        4.98Ki   0.0%
   0.1%  3.80Ki .dynsym            3.80Ki   0.0%
   0.1%  3.17Ki .plt               3.17Ki   0.0%
   0.0%     340 [ELF Headers]      1.86Ki   0.0%
   0.0%  1.58Ki .rel.plt           1.58Ki   0.0%
 100.0%  4.75Mi TOTAL              86.6Mi 100.0%

But for compileuntis or symbols I had this error.

OS: Ubuntu 16.04
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609
clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)

I tried also -g and -ggdb3 flags, same problem

segfault

build from 83fe66b

./bloaty bloaty -d             
bloaty: option '-d' requires an argument
[1]    1316 segmentation fault  ./bloaty bloaty -d

uname -a
Darwin akhanin.local 16.1.0 Darwin Kernel Version 16.1.0: Thu Oct 13 21:26:57 PDT 2016; root:xnu-3789.21.3~60/RELEASE_X86_64 x86_64

otool -L bloaty 
bloaty:
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)

Help should show special options for -d

Help does not show the special values for the -d option as far as I can see, you have to grep the source.

If it's welcome I'll submit a patch.

Files >2GB not supported

$ bloaty large_binary
bloaty: Unknown file type: large_binary
bloaty: error calling munmap(): Invalid argument

This happens since StringPiece from re2, which is used to point to the binary data, stores the length as an int and overflows. This subsequently leads to the failure of CHECK_RETURN(data_.size() >= EI_NIDENT); in elf.cc.

Latest re2 sources seem to correctly use size_t for length, perhaps they could be used:
https://github.com/google/re2/blob/master/re2/stringpiece.h

bloaty does not build with make

Hello,

The README[1] says bloaty can be built with make, but it looks like the project switched to cmake a while back and the README was not updated.

https://github.com/google/bloaty#building-bloaty

Why can readelf list static libraries and their object files, but bloaty not?

assert() triggered with AFL

As discussed through an internal channel, I have been doing fuzzing with AFL and I will file issues on GitHub.

It is possible to trigger this assert() and make the program crash:
https://github.com/google/bloaty/blob/master/src/elf.cc#L375

While this is probably not a critical issue, it hampers fuzzing as this condition is triggered really often. Here is the minimal repro case (per afl-tmin) - unfortunately it is still 10,588 bytes long:

$ xxd input.minimized 
00000000: 7f45 4c46 0101 3030 3030 3030 3030 3030  .ELF..0000000000
00000010: 3030 3030 3030 3030 3030 3030 3000 0000  0000000000000...
00000020: 5c24 0000 3030 3030 3000 3000 3000 2800  \$..00000.0.0.(.
00000030: 2000 3030 3030 3030 3030 3030 3030 3030   .00000000000000
...
00002450: 3030 3030 3030 3030 3030 3030 3030 3030  0000000000000000
00002460: 3030 3030 3030 3030 3030 3030 3000 0000  0000000000000...
00002470: 3000 0000 3030 3030 3030 3030 3030 3030  0...000000000000
00002480: 3030 3030 3030 3030 3030 3030 3030 3030  0000000000000000
...
00002940: 3030 3030 3030 3030 3030 3030 3030 3030  0000000000000000
00002950: 3030 3030 3030 3030 3030 3030            000000000000

$ base64 input.minimized.gz 
H4sICNQVL1gAA2lucHV0Lm1pbmltaXplZADtyrENgDAAA7D0E4YOHXmCTj2BX3i9AlZ4oLKjSBly
HaOXsn9Lctbk3Xdatvx8AQAAAAAAAACAtSV5CrC4CawqtKFcKQAA

Suggestion: use LIEF for parsing?

Hello,

i read recently about bloaty and liked the idea. Today I read about LIEF, which claims, that they implemented a parser for ELF, PE and MachO executables.

Maybe it helps, maybe not, close if not

bloaty: Tried to add range that is not covered by base map.

Passing U-Boot [1] to bloaty [2] results in:

$ make efi-x86_payload32_defconfig all -j12
$ file u-boot
u-boot: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, not stripped
$ bloaty u-boot            
bloaty: Tried to add range that is not covered by base map.
$ gcc --version
gcc (Ubuntu 7.3.0-21ubuntu1~16.04) 7.3.0

Any ideas how to overcome this?

[1] http://git.denx.de/?p=u-boot.git;a=commit;h=5e9a9645816edcc68c09729f257e0c863292bf26
[2] Bloaty commit bdbb3ce ("Merge pull request #125 from timonvo/arm64-support")

Support for Atmel AVR architecture?

Just some information in case someone wants to add support for the Atmel AVR architecture to bloaty.

I have tried analysing an elf-file compiled for the ATmega328P microcontroller (Atmel 8-bit AVR RISC-based architecture), which failed with the error "Unknown ELF machine value: 83'".

The error is raised in elf.cc at line 850 since EM_AVR (value 83) does not get handled there. After a quick look at the documentation of the capstone decompiler, it seems that AVR microcontrollers are not explicitly supported (?). But I gave it a try anyway by selecting the ARM architecture (also RISC-based) with little endian and the resulting bloaty binary seems to be working fine with AVR elf-files after this little addition to the switch statement in the function ElfMachineToCapstone():
case EM_AVR: *arch = CS_ARCH_ARM; *mode = CS_MODE_LITTLE_ENDIAN; break;

Note though, that I do not know much about processor architectures and the way capstone works, so the question remains, if this change introduces problems I am not yet aware of (if anyone could provide additional information in this regard, I'd be grateful).

Many thanks to the developers for this useful tool!

Bad format for regex when trying to use a regex to shorten path to compileunits

Hello,

We're using Automake + Libtool to compile our libraries which invoke the compiler with absolute paths to source files. Down the road, inside our .so files, debug information stores full paths and bloaty's output is unusable:

$ bloaty -d compileunits  ./libfoo.so
     VM SIZE                                                                                        FILE SIZE
 --------------                                                                                  --------------
  29.4%   412Ki [None]                                                                            8.99Mi  90.3%
  30.4%   426Ki [Other]                                                                            426Ki   4.2%
   6.5%  91.3Ki /home/greedo/Projects/Work/SomeProjectRepository/native/libs/foo/_autotools/src/  91.3Ki   0.9%
   3.8%  53.2Ki /home/greedo/Projects/Work/SomeProjectRepository/native/libs/foo/_autotools/src/  53.2Ki   0.5%
   3.7%  51.5Ki /home/greedo/Projects/Work/SomeProjectRepository/native/libs/foo/_autotools/src/  51.5Ki   0.5%
   3.0%  42.5Ki /home/greedo/Projects/Work/SomeProjectRepository/native/libs/foo/_autotools/src/  42.5Ki   0.4%
   2.7%  38.1Ki /home/greedo/Projects/Work/SomeProjectRepository/native/libs/foo/_autotools/src/  38.1Ki   0.4%
   2.5%  35.0Ki /home/greedo/Projects/Work/SomeProjectRepository/native/libs/foo/_autotools/src/  35.0Ki   0.3%
   2.1%  29.9Ki /home/greedo/Projects/Work/SomeProjectRepository/native/libs/foo/_autotools/src/  29.9Ki   0.3%
   2.1%  28.9Ki /home/greedo/Projects/Work/SomeProjectRepository/native/libs/foo/_autotools/src/  28.9Ki   0.3%
   2.1%  28.9Ki /home/greedo/Projects/Work/SomeProjectRepository/native/libs/foo/_autotools/src/  28.9Ki   0.3%
   2.0%  28.1Ki /home/greedo/Projects/Work/SomeProjectRepository/native/libs/foo/_autotools/src/  28.1Ki   0.3%
   1.2%  16.4Ki /home/greedo/Projects/Work/SomeProjectRepository/native/libs/foo/_autotools/src/  16.4Ki   0.2%
   1.2%  16.3Ki /home/greedo/Projects/Work/SomeProjectRepository/native/libs/foo/_autotools/src/  16.3Ki   0.2%
   1.1%  16.0Ki /home/greedo/Projects/Work/SomeProjectRepository/native/libs/foo/_autotools/src/  16.0Ki   0.2%
   1.1%  15.3Ki /home/greedo/Projects/Work/SomeProjectRepository/native/libs/foo/_autotools/src/  15.3Ki   0.2%
   1.1%  15.3Ki /home/greedo/Projects/Work/SomeProjectRepository/native/libs/foo/_autotools/src/  15.3Ki   0.2%
   1.0%  14.4Ki /home/greedo/Projects/Work/SomeProjectRepository/native/libs/foo/_autotools/src/  14.4Ki   0.1%
   1.0%  13.9Ki /home/greedo/Projects/Work/SomeProjectRepository/native/libs/foo/_autotools/src/  13.9Ki   0.1%
   1.0%  13.8Ki /home/greedo/Projects/Work/SomeProjectRepository/native/libs/foo/_autotools/src/  13.8Ki   0.1%
   1.0%  13.8Ki /home/greedo/Projects/Work/SomeProjectRepository/native/libs/foo/_autotools/src/  13.8Ki   0.1%
 100.0%  1.37Mi TOTAL                                                                             9.96Mi 100.0%

In the output above, I redacted the exact project name but I kept the same string length. The problem is that absolute paths to source files are way too long for bloaty's output formating.

I tried using regexes in hope I could improve the output but I'm hitting:

$ bloaty -d compileunits -r compileunits+=/xxx/yyy/ ./libfoo.so
Bad format for regex, should be: source+=/pattern/replacement/

Any idea please?

Tried to add range that is not covered by base map

Trying bloaty on my IAR-compiled embedded executable yields this result.

From the -vvv output it seems that the issue occurs when bloaty is trying to deal with a section that is placed at the "RAM" addresses.

I cannot provide a sample file (sadly), but am willing to help in investigating the issue (such as running arbitrary toolchain commands on the file and extracting information from that).

Create a GitHub release for Bloaty

https://aur.archlinux.org/packages/bloaty-git/

BTW, it would be cool to make a github release.

Catch exceptions in main()?

I expect that exception handling is usually supported by a C++ program. I wonder why your function “main” does not contain corresponding try and catch instructions so far.

How do you think about recommendations by Matthew Wilson in an article?

Would you like to adjust the implementation if you consider effects for uncaught/unhandled exceptions?

Support for stripped files?

My binary size is about 30MB
it is stripped from debug information
the unstripped binary is 250MB
I want to be able to use bloaty on my stripped binary but using the debug information from the unstripped file (this is something any debugger can do)

Also, for Mach-O, Xcode regularly produces stripped files and a dSYM files besides them that contains the symbols information

Allow Input from a config file

Due to the limitation of the debian operating system, a method to pass a large number of file names to bloaty to process would be a great feature. Processing a formatted config file with all the parameters would over come the limit of command line input

Rust symbol demangling

This came up in HN discussion that Bloaty does not have currently demangling for Rust symbols, and such feature would be useful.

There are at least two different libraries that implement Rust demangling:

GNU libiberty: https://github.com/gcc-mirror/gcc/blob/master/libiberty/rust-demangle.c
rustc-demangle: https://github.com/alexcrichton/rustc-demangle

The latter has the downside of being implemented in Rust, so a small wrapper is needed to make it work with C++ code. Might need bit of work to make it play with CMake nicely.

I have made a quick proof of concept version based on rustc-demangle here: https://github.com/zokier/bloaty/tree/rust_demangle

Windows support

Are there plans to support windows? (both in building the tool and analyzing files)?

With some small tweaks(hacks) it builds inside cygwin,
however running it results in an assertion:

$ ./bloaty.exe -vvv tests/testdata/linux-x86/01-empty.o
[segments] AddRange(.text, 0, 0, 34, 0)
[segments] AddRange(.data, 0, 0, 34, 0)
[segments] AddRange(.bss, 0, 0, 160000, 0)
[segments] AddRange(.debug_line, 0, 0, 34, 0)
[segments] AddRange(.debug_str, 0, 0, 34, 0)
[segments] AddRange(.comment, 0, 0, 34, 2c)
[segments] AddRange(.note.GNU-stack, 0, 0, 60, 0)
[segments] AddRange(.shstrtab, 0, 0, 60, 5c)
[segments] AddRange(.symtab, 0, 0, 274, 90)
[segments] AddRange(.strtab, 0, 0, 304, e)
[segments] AddFileRange([ELF Headers], 0, 34)
[segments] AddFileRange([ELF Headers], bc, 1b8)
[segments] AddFileRange([ELF Headers], 0, 0)
[segments] AddFileRange([Unmapped], 0, 312)
WARN(2): adding mapping [0, 312] for label [None], this conflicts with existing mapping [34, 60] for label .comment
WARN: adding mapping [34x, 312x] for label[None], this conflicts with existing mapping [34, 60] for label .comment
WARN: adding mapping [60x, 312x] for label[None], this conflicts with existing mapping [60, bc] for label .shstrtab
WARN(2): adding mapping [bc, 312] for label [None], this conflicts with existing mapping [274, 304] for label .symtab
WARN: adding mapping [274x, 312x] for label[None], this conflicts with existing mapping [274, 304] for label .symtab
WARN: adding mapping [304x, 312x] for label[None], this conflicts with existing mapping [304, 312] for label .strtab
[sections] AddRange(.text, 0, 0, 34, 0)
[sections] AddRange(.data, 0, 0, 34, 0)
[sections] AddRange(.bss, 0, 0, 160000, 0)
[sections] AddRange(.debug_line, 0, 0, 34, 0)
[sections] AddRange(.debug_str, 0, 0, 34, 0)
[sections] AddRange(.comment, 0, 0, 34, 2c)
[sections] AddRange(.note.GNU-stack, 0, 0, 60, 0)
[sections] AddRange(.shstrtab, 0, 0, 60, 5c)
[sections] AddRange(.symtab, 0, 0, 274, 90)
[sections] AddRange(.strtab, 0, 0, 304, e)
[sections] AddFileRange([ELF Headers], 0, 34)
WARN: adding mapping [34x, 34x] for label[ELF Headers], this conflicts with existing mapping [34, 60] for label .comment
WARN: adding mapping [60x, 34x] for label[ELF Headers], this conflicts with existing mapping [60, bc] for label .shstrta                                                                                                                                              b
[sections] AddFileRange([ELF Headers], bc, 1b8)
WARN: adding mapping [274x, 274x] for label[ELF Headers], this conflicts with existing mapping [274, 304] for label .sym                                                                                                                                              tab
WARN: adding mapping [304x, 274x] for label[ELF Headers], this conflicts with existing mapping [304, 312] for label .str                                                                                                                                              tab
[sections] AddFileRange([ELF Headers], 0, 0)
[sections] AddFileRange([Unmapped], 0, 312)
WARN: adding mapping [0x, 312x] for label[Unmapped], this conflicts with existing mapping [0, 34] for label [ELF Headers                                                                                                                                              ]
WARN: adding mapping [34x, 312x] for label[Unmapped], this conflicts with existing mapping [34, 60] for label .comment
WARN: adding mapping [60x, 312x] for label[Unmapped], this conflicts with existing mapping [60, bc] for label .shstrtab
WARN: adding mapping [bcx, 312x] for label[Unmapped], this conflicts with existing mapping [bc, 274] for label [ELF Head                                                                                                                                              ers]
WARN: adding mapping [274x, 312x] for label[Unmapped], this conflicts with existing mapping [274, 304] for label .symtab
WARN: adding mapping [304x, 312x] for label[Unmapped], this conflicts with existing mapping [304, 312] for label .strtab
assertion "current != UINTPTR_MAX" failed: file "src/bloaty.cc", line 1040, function: static void bloaty::RangeMap::Comp                                                                                                                                              uteRollup(const std::vector<const bloaty::RangeMap*>&, const string&, int, Func) [with Func = bloaty::Bloaty::ScanAndRol                                                                                                                                              lupFile(const bloaty::InputFile&, bloaty::Rollup*)::Maps::ComputeRollup(const string&, int, bloaty::Rollup*)::<lambda(co                                                                                                                                              nst std::vector<std::basic_string<char> >&, uint64_t, uint64_t)>; std::string = std::basic_string<char>]
Aborted (core dumped)

Cygwin / g++ versions:

$ uname -a
CYGWIN_NT-10.0-WOW DEV1 2.6.0(0.304/5/3) 2016-08-31 14:27 i686 Cygwin

$ g++ --version
g++ (GCC) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Here are the (hack)-fixes that worked for me to get it to build:

 Makefile               | 2 +-
 src/bloaty.cc          | 4 ++++
 third_party/googletest | 0
 third_party/re2        | 0
 4 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 03ba10c..de19bd2 100644
--- a/Makefile
+++ b/Makefile
@@ -3,7 +3,7 @@
 
 # Disable -Wsign-compare because StringPiece currently unhelpfully defines
 # size() as ssize_t instad of size_t.
-CXXFLAGS=-std=c++11 -ffunction-sections -fdata-sections -Wall -Wno-sign-compare -g -I third_party/re2 -I. -Isrc -O2
+CXXFLAGS=-std=gnu++11 -ffunction-sections -fdata-sections -Wall -Wno-sign-compare -g -I third_party/re2 -I. -Isrc -O2
 RE2_H=third_party/re2/re2/re2.h
 
 ifeq ($(shell uname), Darwin)
diff --git a/src/bloaty.cc b/src/bloaty.cc
index 52ca820..4d8d073 100644
--- a/src/bloaty.cc
+++ b/src/bloaty.cc
@@ -41,6 +41,10 @@
 #include "re2/re2.h"
 #include <assert.h>
 
+#ifdef __CYGWIN__
+#define WEXITED         0
+#endif
+
 #include "bloaty.h"
 //#include "base/init_google.h"
 
diff --git a/third_party/googletest b/third_party/googletest
--- a/third_party/googletest
+++ b/third_party/googletest
@@ -1 +1 @@
-Subproject commit a2b8a8e07628e5fd60644b6dd99c1b5e7d7f1f47
+Subproject commit a2b8a8e07628e5fd60644b6dd99c1b5e7d7f1f47-dirty
diff --git a/third_party/re2 b/third_party/re2
--- a/third_party/re2
+++ b/third_party/re2
@@ -1 +1 @@
-Subproject commit 9efd0dfacc81cc279e135a0e092ff5e9c1d20637
+Subproject commit 9efd0dfacc81cc279e135a0e092ff5e9c1d20637-dirty

And for re2:

 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 411e551..9d8837c 100644
--- a/Makefile
+++ b/Makefile
@@ -17,7 +17,7 @@ CXX?=g++
 CXXFLAGS?=-O3 -g
 LDFLAGS?=
 # required
-RE2_CXXFLAGS?=-std=c++11 -pthread -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -I. $(CCICU) $(CCPCRE)
+RE2_CXXFLAGS?=-std=gnu++11 -pthread -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -I. $(CCICU) $(CCPCRE)
 RE2_LDFLAGS?=-pthread $(LDICU) $(LDPCRE)
 AR?=ar
 ARFLAGS?=rsc

To get gtest to play nice with cygwin, the makefile generator has to be manually specified for cmake (it ran visual studio generators by default).

I am by no means an expert with makefiles, so these hackfixes might not work for other platforms!

bloaty -d compileunits on externally-linked Go binary

$ bloaty -d compileunits bin
bloaty: VM range (32, 8) for label runtime.tlsg extends beyond base map

$ readelf -s bin | grep runtime.tlsg
295838: 0000000000000020     8 TLS     LOCAL  DEFAULT   29 runtime.tlsg

runtime.tlsg is a TLS symbol used by the runtime to allocate a TLS slot for the goroutine pointer in a binary that might need to use libc TLS. Its value is an offset into the TLS block, not an absolute address, so it should probably be ignored by bloaty.

Any go binary built with -ldflags=-linkmode=external should have the symbol and reproduce the problem.

Add option to get more granulatrity from sections view

Bloaty only shows the topmost section name without digging in further, i.e. .text.strncpy et al. It would be nice if I could choose how many levels deep Bloaty displays.

compileunit source for Mach-O

I'm attempting to debug why the prototype gRPC-C++ framework for iOS is so huge and I've come across the limitation that some of the sources (armembers, compileunits, and inlines) aren't supported with the Mach-O file format.

It would be very helpful to add at least compileunit support to help diagnose size problems in frameworks like these.

assert(base) triggered with AFL

As discussed through an internal channel, I have been doing fuzzing with AFL and I will file issues on GitHub.

It is possible to trigger this assert() and make the program crash:
https://github.com/google/bloaty/blob/master/src/bloaty.cc#L501

While this is probably not a critical issue, it hampers fuzzing. Returning false might be a better option. Unfortunately trying to minimize the crash with afl-tmin will result in a different assert() being triggered. Therefore here is the full test case:

$ base64 input.crashing.gz 
H4sICMgYL1gAA2lucHV0LmNyYXNoaW5nAO1bfWwcRxWfvQ/fXc65u8T5sJ1QX5qkTUK9SZPUNQlu
7FycnI3zUddWAsJs9u727IP7MHd7ydmgYBoT4YSIqE1DEP0DkMqHkIC/EM0/5KO0FqKSoQIFCYRp
iUhCpLqFggNSj5mdeXu7c7t2/oCKP+7Zu2/nN+/NvJnZnZ2d9+4L3X37HYKAgJzoKURSP66j6U6G
39ygi2CsHXnwOYw+pMm6kT1d9Jo5wlqEiB6pYm4pReeWhk18xXKKz6/T2AToOZieN0DzvYGwiV9l
TQEO1brYMc1wnkPzNhjkCR25pSbI9T0PTfPcTu9prFeHHpxCjPez+uz6JeRAJg4jR3RWIDJ+CB04
NIhOnX3+8uHWR3f7LnQLA7Pp7JZ7g79DLJ+Y7mD8dFjrIt/3XBPClycf0rB6fATxsbf7N/euvPXc
5yfOFILvnl4ffG91n5fwm589tvbl8+8ECD6H03ffeDvw879e3LRYG53Ih45xnbIWwciaSbDBZRu8
3Qbvx8fDFviPEOnzlcgVNmtd1/BV6PZWM/45fCzD+CzDYZwvaPhKXLkZ/yI+liM/eoG7Ty6xcv7M
lfMTVi9vT0grp7rfiqycTib/zSDFzzJ7jofM+CqtnHo06zGX8yKz82XOTiRJw5lcViqocl6VJCSl
sikVSUnMkNQzcFBKKHllOFVQlfzAwUg6l1UG5FhaoXnWOVK8JJMC5HRqHCd7T0j9TC6SlgsFpYCS
uZxU0s5j2jlZzMZRTM5jkJzHtPO4dtay0qlYXCzkxDYkKQlZlXEdsUKB2oyhbAId6OvZG5G2i9vF
J8ztduA7zPqPErl6CVWey2Jzyke0XmNpeB5hfjnO+m+ew8MM7wyZcUhPBymvQ/SZBJox4E4DftOA
+wz4rAFfYsBvG3CXAZ8z4Mb5e96AG2+5Rmavh7MnbMCN8tHT97zRc+6ML4yiX7qqum+v18BXvDeQ
icpPPItFyhsn8TnY0omvSHqEZN2ZLWPaOE7SZFjuzOBk9Lz7WBMu83xHL2aD0c3z0alb0dPzgZOO
oRu4wr97aYXvDpVnSXlYfh2VbzbIX5t3RqeuR6/d3RMVZqK/mi9qyiv/qCn/GitHp14tv0n0Jzru
N+IWFh+Nnu54DWfjIqZuqfXRcx0ObNftIWzS7RF8GnrVPYMFhb/dSBISgy2TrB86LtdhNfURbNxJ
ZlzzILbnWQzjssozQ3eO4gKCLRNaoz+Gr0kdWLwdi5/zXhkrlUpT0/+8e+1fzqnpa/Mtm69PzQzd
YDJrF5KBcWDdLqxx7g6z8bv4frn8Ucy/j6tLYP465sTiFWxchPF+JJRCwpp6j/eCQOcFMlcfwXrb
iEAgtD/Q2Bv0n/ROoD3Nu7fs2KBNs0RmHz46cHnaXNIVCJ1xRJbWSbgglk/q67LJr1GNalSjGv1v
CNYpYW4dCOuelxivZxzWnexzRF8/NrE0rIPWsDTM4c2Mw3poLZf/3vvlnKbPKoY1SCNbpMBa4ghb
FMGa5g3G/SDPuL4mYesRWEttYxzea9Ds1YxvqjPj7W6znXOMw1oL6sOvQc3+RiZfZmnoxzmWvsfa
c5+ljWun/weC72aeLrF++c4iH7GwjrUjYcHcGtWoRjWqUY1qVKMa1ahGNapRjWr0QRD5Pj8QiewK
bxqMFbNqMbxTbBd3tm4vaqnHTz2+U9y2U9yxmeLoMQRbK3SDhHdv8kTlL+ryVW5Gjog7le6YeAWi
K4wi6ou2qshB9iYEV69FtvCi0+VOZVWk5cbw4SanvzhRnddDXFGavOB4Gp99TnCiekoEdPZqIHh6
tS0xF1IqNp1iNvGN2UVs+gqRcPdaZC9u0xmDTeDA9bxgsAm8zJ5v6C33OcGVjIRlwsZAg98ZWBNY
Jiz3hFZjc0S0p8kZ2OXf7e9pIGBn49f2NiHk3ID8/qf8TjwqLkHoaRAasDXrUE/DVjdCdSwzgCva
iUB7T5Oj8YOqpI30JHqIVCf8O7AUn7UQFYH8J3M5MSfGaZN9Dhj5lb2OMJZbSDMm542aMD6rqGbF
+az5lreqmVFyiN375CdLn1COKlFUSI0r6tioQiIswhH6SIRbM2oxq3QMK1kln4rjpJyPj3SU2tta
23DmcLg1eaQngs8FVY5/pnU0n1OVuJrL6+2g7m6wreLt1p3f4PZGYmEso8oxzNU85SNwlcWlisPZ
ohgrptKJ1lQCaakRuTCCxMRYFmtSruZpzgklX0jlsqaEhPPySlomguxqNK0iUXP9i6pSwmctAEBU
RqRkXs4o0kgiX0lRSUnO5+UxKgnXn47nterlTCqOq8yp2omWrjnuxVihgMR4LpNRsgRTYsVhrCxn
h5UCJFPZZE7PisXyyglIpVNZBa5JC/8LRPazIU6GkF28EJCLS4v4+Ee5nAN92OcG/kmGw34w7/sk
8Sx+Q/2wDw4c7HAxGdCH/elOVjbow746cNhHB+L3aaOI7mmDPuxjA3+Es9/B8UFE98j1+t1mHkYV
+wVU3f6EoW2EYF8eOOzL8/0H7c9y+rDPDxz8AkR/iYV+CVVi1AiBHwQ4+DeA+PEvcPoTdWa+jZMP
cfwUpw/xeMBbuQELmZNoktMHvw1wHyfP23+W6evjbxP3Zqd/mdMPec18kpPnx//b+CAhfjC+lTg4
a3k+/UNE39GgD36o+QfUv8Ls1/014CcJWMvz6Z8hc+xOJU6Rpq8anl+jPozjNFc/xAlNs3iudpv6
gb/O2w9+GlYBH6zH6/+W0wc/TyfTfyVo1g9z5f2elQX6YYiPC0N7Ftb/E6uff05A/8McLnD8Lqqe
0wjBWum4jT7QfRv9rzL9Di6Tl3UL1vq/pPGs6BeL1N9go3+JBTOqi+i3CNb9t2Q95d+y0Qe+DFn7
Kn/A9Lcs0n7js2+km49R3sgmphZmIz//+mzqn9tO+VuL1L8QObH0tIWCE1s8Z4k79feuGXfp71Mz
7tbfk2a8Tn//mXGP/l4z4179fWXGq+NBKb5Ef7+Ycb/+3jDj1fGgFF+qz/NmPKDP32Y8qM/PZjyk
z7tmfFllPjXhyy390U7UoM9/ZnxFZV4z4Sst/dJOtEqfh8z46iqM4o02eJMNzq8KAF9jg6+twsjt
50LvlHm8Xsur7jdiicNifEWGz3J4F8P5+I+jWvmV/oHHIKldV4/jeVbOca6cr2vy1ffDT23addUG
t+sH+l4MoAvcfUjfV9b3lVU5b2ry1ffJ2xpefR/OM3kvd/+4tHm2+j5sFqzj0dsE67hz8j6xiueO
CNbx3D2CdTz3YcE6nvuYYB13/ikbOzOCdRx8XrCOgy8J1vHrk4J1fPxZwTo+/nkbe75rg18TrOP7
/yBYx82jeF4tqMVkEn9rS1JvpF/q63lmQJJQJZ5dUjNSnMStF5AFJEmJnDSczsXktJTA3/EFSS6W
EP5yHU0rqpIQ2z7y5A5rIanyRSzhr9z8GKLf0IliJjOGVQwpqfIhDaJstwD2CSRpf3/XwW6p+9A+
Ep2vtQSuE4WcNCJnEyToft/HD3Ud7IlgdOBgBCQO9B3e29UnHd6//5nuAWmga29ft7RwVD8Nr6db
JHSLgv4UwLRRMV71owESgk/3N4yR+XRTQ99psfolwIP+jKCz0xjhT3+k8B/oNV2Y0zQAAA==

bloaty build failure with musl; bloaty.h uses bswap and friends without proper include

Needs to #include "<byteswap.h>" on glibc and musl, can't speak for other platforms.

edit: That is to say, 'byteswap.h' is the header that should be included on glibc when using these functions, see http://man7.org/linux/man-pages/man3/bswap.3.html . Clearly bloaty builds against glibc as-is, likely one of the headers happens to include 'byteswap.h' for now.

Broken CSV export

bloaty -d sections,rawsymbols ...

     VM SIZE                                                                                        FILE SIZE
 --------------                                                                                  --------------
   0.0%       0 .debug_info                                                                       1.39Mi  28.2%
   0.0%       0 .debug_str                                                                        1.24Mi  25.2%
  74.5%   544Ki .flash                                                                             544Ki  10.8%
      13.6%  74.1Ki [Unmapped]                                                                        74.1Ki  13.6%
...

bloaty --csv -d sections,rawsymbols ...

sections,rawsymbols,vmsize,filesize
.debug_info,0,1455587
.debug_str,0,1304258
.flash,[Unmapped],75908,75908
.flash,nist256p1,37084,37084

I would expect second and third line of the CSV output to be:

.debug_info,,0,1455587
.debug_str,,0,1304258

(extra comma after section name) to match the columns in the header.

Are binaries built for Android expected to work?

Basic things seem to work but I'm running into odd things like this:

$ bloaty libsample.so -d inlines
bloaty: premature EOF skipping DWARF data

Any ideas?

google / bloaty Goto Github PK

bloaty's Introduction

Bloaty: a size profiler for binaries

Install

Support

bloaty's People

Contributors

Stargazers

Watchers

Forkers

bloaty's Issues

Recommend Projects

Recommend Topics

Recommend Org