dwarfprofile
============

Profile binary sizes using dwarf info

Invocation
==========

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

dwarfprofile -p <pid> # profile running process

Dependencies
============

openSUSE:
	sudo zypper in libdw-devel libelf-devel

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

Versions
========

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
https://fedorahosted.org/releases/e/l/elfutils/0.158/

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:
	http://valgrind.org/docs/manual/cl-format.html

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.

[1] http://www.agner.org/optimize/#objconv