# Bloaty McBloatface 1.0

DevFeed: [Bloaty McBloatface 1.0](<https://devfeed.tech/articles/bloaty-mcbloatface-1-0-21132.md>)

Original publisher: [Read original article](<https://blog.reverberate.org/2018/08/07/bloaty-1.0.html>)

Author: Haberman

Published: 2018-08-07T00:00:00Z

Content type: release

Language: en

Sources: [Josh Haberman](<https://devfeed.tech/sources/josh-haberman.md>)

Topics: [Data Quality](<https://devfeed.tech/topics/data-quality.md>), [Parser](<https://devfeed.tech/topics/parser.md>), [OCaml](<https://devfeed.tech/topics/ocaml.md>), [C](<https://devfeed.tech/topics/c.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>)

Tags: [binaries](<https://devfeed.tech/tags/binaries.md>), [bugfixes](<https://devfeed.tech/tags/bugfixes.md>), [c](<https://devfeed.tech/tags/c.md>), [code](<https://devfeed.tech/tags/code.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [data-quality](<https://devfeed.tech/tags/data-quality.md>), [ocaml](<https://devfeed.tech/tags/ocaml.md>), [release](<https://devfeed.tech/tags/release.md>), [symbols](<https://devfeed.tech/tags/symbols.md>)

## AI overview

The article announces Bloaty McBloatface 1.0, a size profiler for ELF and Mach-O binaries. It explains that the release improves data quality by parsing binary sections such as unwind information, DWARF debug information, symbol and string tables, and relocations more thoroughly.

## Source excerpt

Today I am releasing Bloaty McBloatface 1.0. Bloaty is a size profiler for binaries. It helps you peek into ELF/Mach-O binaries to see what is taking up space inside. Bloaty has gotten lots new features, bugfixes, and overall improvements since I announced it in 2016. I listed these changes briefly on the release page, but I wanted to go into a bit more detail here. Improving Data Quality Perhaps the biggest overall improvement to Bloaty is its data quality. When I first announced Bloaty, I got very understandable complaints like this one: I ran it and it gives an awful lot of "[None]": $ ~/d/bloaty/bloaty builder/virt-builder -d compileunits VM SIZE FILE SIZE -------------- -------------- 75.5% 1.96Mi [None] 3.67Mi 85.2% 8.7% 232Ki guestfs-c-actions.c 232Ki 5.3% 8.2% 219Ki guestfs.ml 219Ki 5.0% 2.0% 52.4Ki [Other] 52.4Ki 1.2% 1.3% 33.7Ki _none_ 33.7Ki 0.8% 0.7% 17.5Ki customize_cmdline.ml 17.5Ki 0.4% 0.6% 17.3Ki builder.ml 17.3Ki 0.4% 0.4% 11.8Ki customize_run.ml 11.8Ki 0.3% 0.4% 10.4Ki cmdline.ml 10.4Ki 0.2% 0.3% 7.08Ki firstboot.ml 7.08Ki 0.2% 0.2% 6.21Ki index-scan.c 6.21Ki 0.1% 0.2% 5.90Ki index_parser.ml 5.90Ki 0.1% 0.2% 5.15Ki sigchecker.ml 5.15Ki 0.1% 0.2% 4.87Ki getopt-c.c 4.87Ki 0.1% [...] It's a mixed OCaml/C executable, but I ran it on a build from the local directory and all debug symbols are still available. Indeed, a profiler tool that has no idea what to say about 85.2% of the binary is not going to be very useful. This was Bloaty's biggest weakness when I first released it. At first I misunderstood the nature of this problem. Bloaty's design at the time was simple: it was reading .debug_aranges to assign ranges of the binary to compilation units. DWARF's .debug_aranges section is an {address range -> compileunit} map that debuggers use to decide what compile unit a given function or data variable is from, given its address. The output above indicates that .debug_aranges was only covering about 15% of the binary. What gives? My theory at the time was