gimli-rs/ddbug

Display debugging information

ddbug - Display debugging information

ddbug is a utility for using DWARF debugging information to explore aspects code generation, and in particular to see how the code generation changes due to things such as source code changes or compiler option changes.

Features:

• Type size and layout
• Function type, size, inlined functions, function calls, and disassembly
• Display the differences between two files
• Plain text or HTTP/HTML output
• Options to filter/sort the plain text output

This is alpha software. It is likely to contain many bugs and incomplete features. Neverthless, it is in a state where it can still provide some use. Bug reports and feature requests are welcome.

Supports:

• ELF files with DWARF
• Mach-O files with DWARF

Installing

After installing Rust, run:

cargo install --git https://github.com/gimli-rs/ddbug

Running

Find the file containing the debugging information, then run:

ddbug path-to-file

See ddbug --help for details on options to control which information is displayed.

Usually you will want to run ddbug on binaries that have been optimized, but which still contain debugging information. For rust, you can build your code using:

RUSTFLAGS=-g cargo build --release

Diff mode

When given the --diff option and two paths to files, ddbug will display the differences between the two binaries. There are some command line options to specify which differences are considered significant. Usually you will want to at least ignore addresses (-i address).

Example output

struct and union

struct core::fmt::Formatter
        size: 96
        members:
                0[16]   width: union core::option::Option<usize>
                16[16]  precision: union core::option::Option<usize>
                32[16]  buf: struct core::fmt::&mut Write
                48[16]  curarg: struct core::slice::Iter<core::fmt::ArgumentV1>
                64[16]  args: struct &[core::fmt::ArgumentV1]
                80[4]   flags: u32
                84[4]   fill: char
                88[1]   align: enum core::fmt::rt::v1::Alignment
                89[7]   <padding>

enum

Note that this is a C style enumeration. Rust enumerations are encoded in the debugging information as both a union and an enum.

enum core::result::Result
        size: 1
        enumerators:
                Ok(0)
                Err(1)

function

fn ddbug::main
        linkage name: _ZN5ddbug4mainE
        address: 0x601f0-0x629d9
        size: 10218
        inlined functions:
                [30]    log::__static_max_level
                [59]    log::max_log_level
        calls:
                0x40eee0 env_logger::init
                0x48870 core::result::Result<(), log::SetLoggerError>::ok<(),log::SetLoggerError>

fn log::__static_max_level
        linkage name: _ZN3log18__static_max_levelE
        inline: yes
        return type:
                [8]     enum log::LogLevelFilter

License

This software is licensed under either of

• Apache License, Version 2.0 (LICENSE-APACHE)
• MIT license (LICENSE-MIT)

at your option.

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

ddbug's Issues

Type `Symbol` is public, but there's no way to get one

Symbol is pub, but there doesn't seem to be any public API that can take or return this type.

Expose base type encodings

Base type names differ between different languages, but they're described fairly precisely via DW_AT_encoding + DW_AT_endianity + bit size and offset.

It would be great if ddbug would add ability to print these layout details of base types both in API and CLI.

Better handling of closures

Need to associate closures with the functions that defined them.

Consider switching from memmap crate dependency

https://rustsec.org/advisories/RUSTSEC-2020-0077.html

memmap appears to no longer be maintained.

cargo install fails

There is a compile error at head.

cargo --version
cargo 1.34.0 (6789d8a0a 2019-04-01)

cargo install --git https://github.com/gimli-rs/ddbug

   Compiling ddbug v0.2.0 (https://github.com/gimli-rs/ddbug#8c162c40)
error[E0106]: missing lifetime specifier
   --> C:\Users\dolson\.cargo\git\checkouts\ddbug-36c848acbe6c76f0\8c162c4\main\src\code.rs:108:9
    |
108 |     cs: capstone::Capstone,
    |         ^^^^^^^^^^^^^^^^^^ expected lifetime parameter

error: aborting due to previous error

Handle large files

Currently ddbug parses everything into memory. Instead, it should do an initial pass that only parses what is needed for sorting and correlation, and then when displaying entries the full values only need to be stored temporarily.

ddbug prints the wrong strings for object file.

Running ddbug on https://people-mozilla.org/~jmuizelaar/tmp/webrender-710bba83bc2d83b7.0.o.gz

prints 'rustc version 1.18.0-nightly (2564711e8 2017-04-04)' for every string.

functions with multiple address ranges

Do you plan to change the function implementation to support functions with multiple ranges? It seems this is supported in addr2line, but here they are presumed to have only one range.

Display annotated disassembly

Display the disassembled instructions for each function, and annotate with information from the DWARF. Desired information:

• variables associated with operands of instructions
• file/line, and inlined function if applicable

Optimization is going to make this hard to display in a sensible manner, but I'm hopeful at least some useful information is possible.

This probably requires HTML output to be usable (see #4).

Export to other formats?

Hi, I'm using ddbug for reverse-engineering a binary (that, as luck would have it, includes dwarf) - in fact, it's pretty much the only tool I was able to find that can understand (the helplessly outdated) DWARF 2 correctly (without segfaulting (dwarfdump, readelf), hanging (IDA), producing completely wrong output (pyelftools) or simply refusing to load the binary (gdb)).

After playing around with the html export, I began wondering if other exports would make sense to you?
How about JSON (for further processing), C-Style header files (at least for functions, structs, enums) and maybe even idc-Files for use with IDA?
I began implementing JSON export by adding serde to many of the internal data structures, but I was wondering if that would even be something you'd be interested in? It would probably require changes in the way you keep track of data - for instance an EnumerationType currently doesn't know any of it's enumerators without being given the File - this doesn't play too well with serde's way of serializing data ;-)

So this "issue" is pretty much a request for discussion - would you like to see more outputs such as JSON and are you open for changes to the data structures should those be needed?

two dimens array & bit size error

Hi ，I found a problem, may need attention
test:
typedef struct
{
/* data */
char name;
short int aaaaa[5];
short int bbb[2][3];
short int proType1:4;
short int proType2:10;

}test_elf;

result:
type test_elf = struct
size: 26
members:
0[1] name: char
1[1]
2[10] aaaaa: [short int; 5]
12[6] bbb: [short int; 3]//size should be 12,not 6,and rows=2,cols=3 can show?
18[6]
24[0.4] proType1: short int**//size should be 0.5byte**
24.4[1.2] proType2: short int**//1.25byte**
25.6[0.2] //0.25byte

Add the ability to print local variables

This could be handy.

union offset is not correct

Hi, I'm learning rust and make a test for ddbug recently. found an error like this:
union A
{
unsigned int v;
struct
{
unsigned int a:4;
unsigned int b:2;
unsigned int c:16;
unsigned int d:1;
unsigned int e:2;
unsigned int f:4;
}b;
}

result is:
type A = union
size: 4
members:
0[4] v: unsigned int
0[4] b: struct ::
0[0.4] a: unsigned int
0.4[0.2] b: unsigned int
0.6[2] c: unsigned int
2.6[0.1] d: unsigned int
2.7[0.2] e: unsigned int
3.1[0.4] f: unsigned int

The offset 3.1 is wrong.should be 2.9, please know.

Publish on crates.io

So I can cargo install ddbug ;)

Add a query interface?

Perhaps ddbug can provide a interface to query the given struct/union, such as:

typedef struct xxx{
int aa;
int bb;
}xxx_tag;

Input the xxx/xxx_tag，ddbug can output struct info like this:

type xxx_tag = struct xxx
size: 8
members:
0[4] aa:int
8[4] bb:int

And if there is a struct-nesting, also output nested structs info.
Even support multi-threads to query, ddbug can be a great tool for debugging.

cargo install ddbug fails right now

Looks related to pdb things -- perhaps there was a breaking change that snuck in as non-breaking or something?

$ cargo install -f ddbug
    Updating registry `https://github.com/rust-lang/crates.io-index`
  Installing ddbug v0.1.0
 Downloading arrayvec v0.3.24
 Downloading odds v0.2.26
   Compiling odds v0.2.26
   Compiling libc v0.2.34
   Compiling scroll v0.5.0
   Compiling uuid v0.5.1
   Compiling winapi-build v0.1.1
   Compiling regex-syntax v0.3.9
   Compiling unicode-xid v0.0.4
   Compiling winapi v0.2.8
   Compiling plain v0.0.2
   Compiling nodrop v0.1.12
   Compiling fallible-iterator v0.1.3
   Compiling quote v0.3.15
   Compiling utf8-ranges v0.1.3
   Compiling byteorder v1.2.1
   Compiling log v0.3.8
   Compiling getopts v0.2.15
   Compiling synom v0.11.3
   Compiling kernel32-sys v0.2.2
   Compiling pdb v0.1.6
   Compiling memchr v0.1.11
   Compiling arrayvec v0.3.24
   Compiling syn v0.11.11
   Compiling thread-id v2.0.0
   Compiling fs2 v0.2.5
   Compiling aho-corasick v0.5.3
   Compiling thread_local v0.2.7
   Compiling gimli v0.14.0
   Compiling memmap v0.4.0
   Compiling regex v0.1.80
   Compiling scroll_derive v0.4.0
   Compiling goblin v0.0.10
   Compiling env_logger v0.3.5
   Compiling ddbug v0.1.0
error[E0433]: failed to resolve. Could not find `EnumValue` in `pdb`
   --> /home/fitzgen/.cargo/registry/src/github.com-1ecc6299db9ec823/ddbug-0.1.0/src/pdb.rs:625:26
    |
625 |                     pdb::EnumValue::U8(val) => val as i64,
    |                          ^^^^^^^^^ Could not find `EnumValue` in `pdb`

error[E0433]: failed to resolve. Could not find `EnumValue` in `pdb`
   --> /home/fitzgen/.cargo/registry/src/github.com-1ecc6299db9ec823/ddbug-0.1.0/src/pdb.rs:626:26
    |
626 |                     pdb::EnumValue::U16(val) => val as i64,
    |                          ^^^^^^^^^ Could not find `EnumValue` in `pdb`

error[E0433]: failed to resolve. Could not find `EnumValue` in `pdb`
   --> /home/fitzgen/.cargo/registry/src/github.com-1ecc6299db9ec823/ddbug-0.1.0/src/pdb.rs:627:26
    |
627 |                     pdb::EnumValue::U32(val) => val as i64,
    |                          ^^^^^^^^^ Could not find `EnumValue` in `pdb`

error[E0433]: failed to resolve. Could not find `EnumValue` in `pdb`
   --> /home/fitzgen/.cargo/registry/src/github.com-1ecc6299db9ec823/ddbug-0.1.0/src/pdb.rs:628:26
    |
628 |                     pdb::EnumValue::U64(val) => val as i64,
    |                          ^^^^^^^^^ Could not find `EnumValue` in `pdb`

error[E0433]: failed to resolve. Could not find `EnumValue` in `pdb`
   --> /home/fitzgen/.cargo/registry/src/github.com-1ecc6299db9ec823/ddbug-0.1.0/src/pdb.rs:629:26
    |
629 |                     pdb::EnumValue::I8(val) => val as i64,
    |                          ^^^^^^^^^ Could not find `EnumValue` in `pdb`

error[E0433]: failed to resolve. Could not find `EnumValue` in `pdb`
   --> /home/fitzgen/.cargo/registry/src/github.com-1ecc6299db9ec823/ddbug-0.1.0/src/pdb.rs:630:26
    |
630 |                     pdb::EnumValue::I16(val) => val as i64,
    |                          ^^^^^^^^^ Could not find `EnumValue` in `pdb`

error[E0433]: failed to resolve. Could not find `EnumValue` in `pdb`
   --> /home/fitzgen/.cargo/registry/src/github.com-1ecc6299db9ec823/ddbug-0.1.0/src/pdb.rs:631:26
    |
631 |                     pdb::EnumValue::I32(val) => val as i64,
    |                          ^^^^^^^^^ Could not find `EnumValue` in `pdb`

error[E0433]: failed to resolve. Could not find `EnumValue` in `pdb`
   --> /home/fitzgen/.cargo/registry/src/github.com-1ecc6299db9ec823/ddbug-0.1.0/src/pdb.rs:632:26
    |
632 |                     pdb::EnumValue::I64(val) => val as i64,
    |                          ^^^^^^^^^ Could not find `EnumValue` in `pdb`

error[E0308]: mismatched types
  --> /home/fitzgen/.cargo/registry/src/github.com-1ecc6299db9ec823/ddbug-0.1.0/src/pdb.rs:98:52
   |
98 |                 let return_type = parse_type_index(return_type);
   |                                                    ^^^^^^^^^^^ expected u32, found enum `std::option::Option`
   |
   = note: expected type `u32`
              found type `std::option::Option<u32>`
   = help: here are some functions which might fulfill your needs:
           - .unwrap()
           - .unwrap_or_default()

error[E0308]: mismatched types
   --> /home/fitzgen/.cargo/registry/src/github.com-1ecc6299db9ec823/ddbug-0.1.0/src/pdb.rs:121:58
    |
121 |                 let this_pointer_type = parse_type_index(this_pointer_type);
    |                                                          ^^^^^^^^^^^^^^^^^ expected u32, found enum `std::option::Option`
    |
    = note: expected type `u32`
               found type `std::option::Option<u32>`
    = help: here are some functions which might fulfill your needs:
            - .unwrap()
            - .unwrap_or_default()

error: aborting due to 10 previous errors

error: failed to compile `ddbug v0.1.0`, intermediate artifacts can be found at `/tmp/cargo-install.W6V5RnUkIBZg`

Caused by:
  Could not compile `ddbug`.

To learn more, run the command again with --verbose.

Release new version

panopticon is still a blocker for this though.

Merge codegen units

rust's support for splitting into multiple codegen units makes it harder to compare differences. Can we optionally merge them back together again?

differentiate reconstructed symbol table based entries

I realized that when the debuginfo is missing for a symbol table entry, ddbug still outputs the entry with whatever it finds in the symbol table.

This is great! However, it did mislead me by thinking the debuginfo was emitted (when it wasn't), and this was something I was specifically investigating.

Is it possible to add for these cases something like a (no debug info) field or (reconstructed) or something, in order to flag it?

Expose inherited types

It would be nice to print the types a struct inherits from. (DW_TAG_inheritance)

Can `ddbug_parser::File::parse` return a `ddbug::File` object?

Hi, the ddbug_parser is very nice and useful for me. Thanks for your work!

I meet trouble when I try to code with ddbug_parser. I want to implement a method that can return dwarf variable information of the given variable location (function address with CFA address / global address/register/register offset).

It seems that I cant hold ddbug_parser::File once ddbug_parser::File::parse finished. Are there any solutions or suggestions?

Make it easier to determine panic locations

One of the original motivations for this tool was to be able to generate a list of panics which weren't optimized away, and to compare changes to this list for different versions of a binary. I'm not sure if the current output format of ddbug is very useful for this. Consider adding a mode to display just this information, or alternatively add another standalone tool to do this.

Display stack layout

Use DWARF locations to determine the stack layout.

Interactive output

As the output gets more detailed, running in batch mode becomes less useful, because you want to drill down on the details as you are viewing the output.

The easiest way is probably to generate something viewable in a web browser.

Expose more APIs from the crate?

Generally dealing with different types of debug information, in particular DWARF vs PDB, and then parsing different types of attributes in different formats into meaningful structures is quite painful.

It looks like ddbug solved most of these issues providing a consistent higher-level interface on top of lower-level gimli, object and pdb APIs, but doesn't expose them in the API (https://docs.rs/ddbug/0.2.0/ddbug/struct.File.html is opaque and allows only printing it out).

I wonder if it would make sense to either extract these APIs into a separate crate or expose them in the API of the library part of this one?

I understand these are subject to breaking changes over time, but having such starting point would be still much nicer than trying to reimplement all of it myself.

add color

I don't know if this a planned feature or on your mind, but it sure would be great :D