Skip to content
Profile binary sizes using dwarf info
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.



Profile binary sizes using dwarf info


dwarfprofile -e <path/to/binary/or/dso> # analyse a single object

dwarfprofile -p <pid> # profile running process


	sudo zypper in libdw-devel libelf-devel

	sudo yum install elfutils-libelf-devel elfutils-libelf elfutils-libs elfutils-devel


elfutils versions prior to 0.157 do not correctly handle the DWARF
output generated by current compilers. This is exhibited by having -ve
lengths for sections and lexical blocks with null names.

The source for elfutils is available from

The current version (0.158) builds correctly (usual ./configure && make)
regardless of libc and binutils versions.

LO output format

This profile is *purely* the actual used text (no data). It indicates the
cumulative total size (in bytes) and usage count for each component
(function/method) in a heirachical structure.

A method may have one or more lexical dwarf blocks within it, the
storage in these blocks is credited to the enclosing scope (the
method) but will increase the use count of the parent function
incorrectly. Because of this small use counts may be off by one and
alter the average excessively.

The output is repeated at different depths. A | indicates that the
line includes all the elements below that depth.

For example:

 Breakdown at depth 2

Total Size    Count   Av. M Element
  23214997  2001524   11                ssd1
  23211463  2001366   11                 lo
  17425180  1739325   10 |                master-suse
   5786283   262041   22 |                android
      2176      110   19                 ndk-toolchain
      2176      110   19 |                src

shows the beginning of a depth 2 output which means any elements below
a depth of two are merged togetehr. In this case it shows that the
ssd1/lo/master-suse source directory produced 17425180 bytes of code
in 1739325 references

Callgrind format

Some rough notes on the callgrind format. Details and examples are here:

The 'main' function is magic for kcachegrind it seems; so we need to
rename existing 'main' functions and insert a top-level to which
everything belongs.

Mach-o x86 binaries

Mach-o apple binaries ship their dwarf section in a separate binary.

The objconv[1] tool can be used to convert these into elf binaries
which dwarfprofile can read.


You can’t perform that action at this time.