gimli-rs / gimli Goto Github PK

View Code? Open in Web Editor NEW

822.0 16.0 105.0 4.26 MB

A library for reading and writing the DWARF debugging format

Home Page: https://docs.rs/gimli/

License: Apache License 2.0

Rust 99.98% Shell 0.02%

dwarf rust cross-platform

gimli's Introduction

`gimli`

gimli is a library for reading and writing the DWARF debugging format.

Zero copy: everything is just a reference to the original input buffer. No copies of the input data get made.
Lazy: you can iterate compilation units without parsing their contents. Parse only as many debugging information entry (DIE) trees as you iterate over. gimli also uses DW_AT_sibling references to avoid parsing a DIE's children to find its next sibling, when possible.
Cross-platform: gimli makes no assumptions about what kind of object file you're working with. The flipside to that is that it's up to you to provide an ELF loader on Linux or Mach-O loader on macOS.
- Unsure which object file parser to use? Try the cross-platform object crate. See the gimli-examples crate for usage with gimli.

Install

Add this to your Cargo.toml:

[dependencies]
gimli = "0.31.0"

The minimum supported Rust version is:

1.60.0 for the read feature and its dependencies.
1.65.0 for other features.

Documentation

Documentation on docs.rs
Example programs:
- A simple .debug_info parser
- A simple .debug_line parser
- A dwarfdump clone
- An addr2line clone
- ddbug, a utility giving insight into code generation by making debugging information readable.
- dwprod, a tiny utility to list the compilers used to create each compilation unit within a shared library or executable (via DW_AT_producer).
- dwarf-validate, a program to validate the integrity of some DWARF and its references between sections and compilation units.

License

Licensed under either of

Apache License, Version 2.0 (LICENSE-APACHE or https://www.apache.org/licenses/LICENSE-2.0)
MIT license (LICENSE-MIT or https://opensource.org/licenses/MIT)

at your option.

Contribution

See CONTRIBUTING.md for hacking.

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.

gimli's People

Contributors

Stargazers

Watchers

Forkers

tromey nrc khuey jvns kamalmarhubi fitzgen philipc bryteise llogiq yodalee borman grissiom xd009642 gchamp20 main-- nvzqz danburkert bluss sfackler ignatenkobrain luser xmartinez lkpdn est31 data-pup gilescope gz roblabla bjorn3 mitsuhiko pombredanne yurydelendik jan-auer asbish silwol whitequark eclipseo anderender vaibspider calixteman ajnam12 alexcrichton slonopotamus nsmryan jrmuizel spwilson2 hermit-os nbaksalyar hhirtz expixel philippeitis rreverser repnop hudsonft the8472 strogo bnjbvr icodein koute ldm0 mstange ayrtonm immunant jdginn nbdd0121 adv-sw swatinem vitonzhangtt saethlin 5225225 skarsh prateekvishnu peamaeq cactter zhaixiaojuan thinkeryzu1 shuoli84 jswrenn swmobile bzeq kjtsanaktsidis chioni16 tamird yoshuawuyts imbillow guillaumegomez nofr33bugs al13n321 georgewort tmcgilchrist sk83rjosh enselic bugadani gnomeddev lesuerchumk rhelmot crzysdrs jameysharp mrmaxmeier marxin

gimli's Issues

Consider adding Index trait syntax sugar for things that take FooOffset types

This occurred to me when doing DebugStr but I didn't write the code for it. Instead of having doing

debug_str.get_str(offset)

Perhaps we should do

debug_str[offset]

What do you think, @fitzgen?

Our `addr2line` fails to symbolicate many addresses that `atos` happily will on OSX

Discovered in #53 (comment).

Grab a bunch of addresses in an executable:

export ADDRS=$(gobjdump -C -x --disassemble -l $EXEFILE | grep callq -C 4 | grep -v '\-\-' | cut -f1 -d':' | grep -v Users | head -n 100)

Run them through atos and every single one gets symbolicated:

$ atos -o $EXEFILE $ADDRS
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:60)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:60)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:60)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwChildren$u20$as$u20$core..fmt..Debug$GT$::fmt::h70fefef2193310dc (in gimli-2ffa6594baf9fafb) (constants.rs:59)
core::fmt::Formatter::debug_tuple::h0f409db74a587b9c (in gimli-2ffa6594baf9fafb) (mod.rs:1242)
core::fmt::Formatter::debug_tuple::h0f409db74a587b9c (in gimli-2ffa6594baf9fafb) (mod.rs:1242)
core::fmt::Formatter::debug_tuple::h0f409db74a587b9c (in gimli-2ffa6594baf9fafb) (mod.rs:1242)
core::fmt::Formatter::debug_tuple::h0f409db74a587b9c (in gimli-2ffa6594baf9fafb) (mod.rs:1242)
core::fmt::Formatter::debug_tuple::h0f409db74a587b9c (in gimli-2ffa6594baf9fafb) (mod.rs:1242)
core::fmt::Formatter::debug_tuple::h0f409db74a587b9c (in gimli-2ffa6594baf9fafb) (mod.rs:1241)
core::fmt::Formatter::debug_tuple::h0f409db74a587b9c (in gimli-2ffa6594baf9fafb) (mod.rs:1241)
core::fmt::Formatter::debug_tuple::h0f409db74a587b9c (in gimli-2ffa6594baf9fafb) (mod.rs:1241)
_$LT$$RF$$u27$a$u20$T$u20$as$u20$core..fmt..Debug$GT$::fmt::hc8069a5290f08723 (in gimli-2ffa6594baf9fafb) (mod.rs:1350)
_$LT$$RF$$u27$a$u20$T$u20$as$u20$core..fmt..Debug$GT$::fmt::hc8069a5290f08723 (in gimli-2ffa6594baf9fafb) (mod.rs:1350)
_$LT$$RF$$u27$a$u20$T$u20$as$u20$core..fmt..Debug$GT$::fmt::hc8069a5290f08723 (in gimli-2ffa6594baf9fafb) (mod.rs:1350)
_$LT$$RF$$u27$a$u20$T$u20$as$u20$core..fmt..Debug$GT$::fmt::hc8069a5290f08723 (in gimli-2ffa6594baf9fafb) (mod.rs:1360)
_$LT$$RF$$u27$a$u20$T$u20$as$u20$core..fmt..Debug$GT$::fmt::hc8069a5290f08723 (in gimli-2ffa6594baf9fafb) (mod.rs:1360)
_$LT$$RF$$u27$a$u20$T$u20$as$u20$core..fmt..Debug$GT$::fmt::hc8069a5290f08723 (in gimli-2ffa6594baf9fafb) (mod.rs:1360)
_$LT$$RF$$u27$a$u20$T$u20$as$u20$core..fmt..Debug$GT$::fmt::hc8069a5290f08723 (in gimli-2ffa6594baf9fafb) (mod.rs:1360)
_$LT$$RF$$u27$a$u20$T$u20$as$u20$core..fmt..Debug$GT$::fmt::hc8069a5290f08723 (in gimli-2ffa6594baf9fafb) (mod.rs:1360)
_$LT$$RF$$u27$a$u20$T$u20$as$u20$core..fmt..Display$GT$::fmt::h651d6adfb7b50255 (in gimli-2ffa6594baf9fafb) (mod.rs:1350)
_$LT$$RF$$u27$a$u20$T$u20$as$u20$core..fmt..Display$GT$::fmt::h651d6adfb7b50255 (in gimli-2ffa6594baf9fafb) (mod.rs:1350)
_$LT$$RF$$u27$a$u20$T$u20$as$u20$core..fmt..Display$GT$::fmt::h651d6adfb7b50255 (in gimli-2ffa6594baf9fafb) (mod.rs:1350)
_$LT$$RF$$u27$a$u20$T$u20$as$u20$core..fmt..Display$GT$::fmt::h651d6adfb7b50255 (in gimli-2ffa6594baf9fafb) (mod.rs:1360)
_$LT$$RF$$u27$a$u20$T$u20$as$u20$core..fmt..Display$GT$::fmt::h651d6adfb7b50255 (in gimli-2ffa6594baf9fafb) (mod.rs:1360)
_$LT$$RF$$u27$a$u20$T$u20$as$u20$core..fmt..Display$GT$::fmt::h651d6adfb7b50255 (in gimli-2ffa6594baf9fafb) (mod.rs:1360)
_$LT$$RF$$u27$a$u20$T$u20$as$u20$core..fmt..Display$GT$::fmt::h651d6adfb7b50255 (in gimli-2ffa6594baf9fafb) (mod.rs:1360)
_$LT$$RF$$u27$a$u20$T$u20$as$u20$core..fmt..Display$GT$::fmt::h651d6adfb7b50255 (in gimli-2ffa6594baf9fafb) (mod.rs:1360)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:60)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:60)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:60)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:59)
_$LT$gimli..constants..DwTag$u20$as$u20$core..fmt..Debug$GT$::fmt::h955b807caedfbf43 (in gimli-2ffa6594baf9fafb) (constants.rs:59)

Try and do the same with our addr2line and only a handful symbolicate:

$ cargo run --example addr2line -- -e $DBGFILE $ADDRS
     Running `target/debug/examples/addr2line -e /Users/fitzgen/src/gimli/target/debug/gimli-2ffa6594baf9fafb.dSYM/Contents/Resources/DWARF/gimli-2ffa6594baf9fafb 100000f3a 100000f3c 100000f43 100000f4a 100000f50 100000f55 100000f5c 100000f5f 100000f65 100000f55 100000f5c 100000f5f 100000f65 100000f6c 100000f71 100000f75 100000f79 100000f7d 100000f89 100000f8d 100000f91 100000f98 100000f9f 100000fa4 100000fa8 100000faf 100000fbf 100000fc3 100000fc7 100000fcb 100000fd0 100000fd4 100000fd8 100000fdc 100000fd0 100000fd4 100000fd8 100000fdc 100000fe0 100000fe5 100000fe8 100000feb 100000fee 100001017 10000101b 10000101f 100001023 100001027 10000102c 100001030 100001034 100001060 100001064 100001067 10000106b 100001070 100001073 100001076 100001079 100001114 100001117 10000111b 10000111f 100001124 100001127 10000112a 10000112d 1000011ea 1000011ec 1000011f3 1000011fa 100001200 100001205 10000120c 10000120f 100001215 100001205 10000120c 10000120f 100001215 10000121c 100001221 100001225 100001229 10000122d 100001239 10000123d 100001241 100001248 10000124f 100001254 100001258 10000125f 10000126f 100001273 100001277 10000127b 100001280 100001284 100001288`
Failed to find matching line for 4294971194
Failed to find matching line for 4294971196
Failed to find matching line for 4294971203
Failed to find matching line for 4294971210
Failed to find matching line for 4294971216
Failed to find matching line for 4294971221
Failed to find matching line for 4294971228
Failed to find matching line for 4294971231
Failed to find matching line for 4294971237
Failed to find matching line for 4294971221
Failed to find matching line for 4294971228
Failed to find matching line for 4294971231
Failed to find matching line for 4294971237
Failed to find matching line for 4294971244
Failed to find matching line for 4294971249
Failed to find matching line for 4294971253
Failed to find matching line for 4294971257
Failed to find matching line for 4294971261
Failed to find matching line for 4294971273
/Users/fitzgen/src/gimli/src/constants.rs:59
Failed to find matching line for 4294971281
Failed to find matching line for 4294971288
Failed to find matching line for 4294971295
Failed to find matching line for 4294971300
Failed to find matching line for 4294971304
Failed to find matching line for 4294971311
Failed to find matching line for 4294971327
Failed to find matching line for 4294971331
Failed to find matching line for 4294971335
/Users/fitzgen/src/gimli/src/constants.rs:59
Failed to find matching line for 4294971344
Failed to find matching line for 4294971348
Failed to find matching line for 4294971352
Failed to find matching line for 4294971356
Failed to find matching line for 4294971344
Failed to find matching line for 4294971348
Failed to find matching line for 4294971352
Failed to find matching line for 4294971356
Failed to find matching line for 4294971360
Failed to find matching line for 4294971365
Failed to find matching line for 4294971368
Failed to find matching line for 4294971371
Failed to find matching line for 4294971374
/Users/rustbuild/src/rust-buildbot/slave/stable-dist-rustc-mac/build/obj/../src/libcore/fmt/mod.rs:1242
Failed to find matching line for 4294971419
Failed to find matching line for 4294971423
Failed to find matching line for 4294971427
Failed to find matching line for 4294971431
/Users/rustbuild/src/rust-buildbot/slave/stable-dist-rustc-mac/build/obj/../src/libcore/fmt/mod.rs:1241
Failed to find matching line for 4294971440
Failed to find matching line for 4294971444
/Users/rustbuild/src/rust-buildbot/slave/stable-dist-rustc-mac/build/obj/../src/libcore/fmt/mod.rs:1350
Failed to find matching line for 4294971492
Failed to find matching line for 4294971495
/Users/rustbuild/src/rust-buildbot/slave/stable-dist-rustc-mac/build/obj/../src/libcore/fmt/mod.rs:1360
Failed to find matching line for 4294971504
Failed to find matching line for 4294971507
Failed to find matching line for 4294971510
Failed to find matching line for 4294971513
Failed to find matching line for 4294971668
Failed to find matching line for 4294971671
Failed to find matching line for 4294971675
/Users/rustbuild/src/rust-buildbot/slave/stable-dist-rustc-mac/build/obj/../src/libcore/fmt/mod.rs:1360
Failed to find matching line for 4294971684
Failed to find matching line for 4294971687
Failed to find matching line for 4294971690
Failed to find matching line for 4294971693
Failed to find matching line for 4294971882
Failed to find matching line for 4294971884
Failed to find matching line for 4294971891
Failed to find matching line for 4294971898
Failed to find matching line for 4294971904
Failed to find matching line for 4294971909
Failed to find matching line for 4294971916
Failed to find matching line for 4294971919
Failed to find matching line for 4294971925
Failed to find matching line for 4294971909
Failed to find matching line for 4294971916
Failed to find matching line for 4294971919
Failed to find matching line for 4294971925
Failed to find matching line for 4294971932
Failed to find matching line for 4294971937
Failed to find matching line for 4294971941
Failed to find matching line for 4294971945
Failed to find matching line for 4294971949
Failed to find matching line for 4294971961
/Users/fitzgen/src/gimli/src/constants.rs:59
Failed to find matching line for 4294971969
Failed to find matching line for 4294971976
Failed to find matching line for 4294971983
Failed to find matching line for 4294971988
Failed to find matching line for 4294971992
Failed to find matching line for 4294971999
Failed to find matching line for 4294972015
Failed to find matching line for 4294972019
Failed to find matching line for 4294972023
/Users/fitzgen/src/gimli/src/constants.rs:59
Failed to find matching line for 4294972032
Failed to find matching line for 4294972036
Failed to find matching line for 4294972040

Re-evaluate deriving Copy

It is easy to accidentally make copies when you didn't intend to, which leads to pretty surprising behavior until you figure out what's up. We should go through each place we derive Copy and re-evaluate whether that impl is providing value or not.

cc @kamalmarhubi

Implement support for .debug_loc

Section 2.6.2 Location Lists

Handle errors in attribute iteration

EntriesCursor::next_dfs doesn't handle errors:
https://github.com/fitzgen/gimli/blob/8e4eb3ce54a966b5bd17b396ff279858d794b162/src/parser.rs#L3388-L3389

EntriesCursor::next_sibling has a related problem at: https://github.com/fitzgen/gimli/blob/8e4eb3ce54a966b5bd17b396ff279858d794b162/src/parser.rs#L3526

Part of the problem is that AttrsIter::next leaves the iterator in a state that won't continue to give errors: https://github.com/fitzgen/gimli/blob/8e4eb3ce54a966b5bd17b396ff279858d794b162/src/parser.rs#L3091. So if an error does occur, the next DIE will start being parsed at wherever the error occurred, with unpredictable results.

(Note: the above is all from code inspection, I haven't tested this happens yet, so I may be mistaken.)

It's easy to get this wrong when using Option<Result<...>>. We could switch to Result<Option<...>>, but that loses the ergonomics of for loops. Some of the iterator functions can be retained using https://github.com/sfackler/rust-fallible-iterator.

Add support for dynamic endianity

@philipc says:

I think we still need something that is runtime selectable as well though. https://github.com/gimli-rs/gimli/blob/master/examples/dwarfdump.rs#L79-L83 is fine for simple utilities, but we need some way to stop the endianity bubbling up through all the APIs.

Implement support for looking up .debug_pubnames and .debug_pubtypes definitions

Section 6.1.1 of the DWARF 4 standard.

LineNumberProgramHeader can't reliably iterate twice

LineNumberProgramHeader::file_names has interior mutability, which is incompatible with multiple StateMachines using it.

add functions to help with EvaluationContext

A couple of the callbacks in EvaluationContext can be implemented without needing anything external to DWARF. In particular frame_base, call_frame_cfa, and get_at_location refer to other DWARF constructs.

It would be helpful to library users to provide an implementation of these methods that could be easily reused.

addr2line doesn't report lines that start before the requested address

Related to #72 and #77.

line::StateMachine::run_to_address requires an exact address match. We should change it to stop at the first row that contains the address. This will need to take sequences into account.

Investigate using the test-assembler crate for programmatically building binary test input

https://crates.io/crates/test-assembler

Would make some of these big binary test inputs easier to construct. It's a Rust port of a similar library @jimblandy wrote when writing Google Breakpad's DWARF CFI support.

Worth adopting?

Fill out top level lib.rs module documentation

This is the entry point to the docs, so it should have pretty much a full tutorial and really good examples about how to use the library.

addr2line: use DW_AT_ranges

Related to #72 and #77.

We should use the DW_AT_ranges attribute to determine which addresses are contained in a compilation unit.

StateMachine::execute shouldn't be public

Being public is just an opportunity for users to mess up the line number program and shoot themselves in the foot (say by defining a file when the rest of the program didn't expect that yet).

We really just want it unit-testable which it can be without being public.

It also means we worry about having a "nice" return type when we shouldn't need to worry about that since it should be an internal thing.

Implement support for .debug_macinfo

Section 6.3 of the standard.

Some languages, such as C and C++, provide a way to replace text in the source program with macros defined either in the source file itself, or in another file included by the source file. Because these macros are not themselves defined in the target language, it is difficult to represent their definitions using the standard language constructs of DWARF. The debugging information therefore reflects the state of the source after the macro definition has been expanded, rather than as the programmer wrote it. The macro information table provides a way of preserving the original source in the debugging information.

As described in Section 3.1.1, the macro information for a given compilation unit is represented in the .debug_macinfo section of an object file. The macro information for each compilation unit is represented as a series of “macinfo” entries. Each macinfo entry consists of a “type code” and up to two additional operands. The series of entries for a given compilation unit ends with an entry containing a type code of 0.

Investigate using quickcheck

Kind of like a fuzzer. Not sure if it would be useful for this library? Worth investigating; I hear great things.

Figure out how to get coveralls.io to understand benches, integration tests, and examples

Right now, AFAICT, it only considers what is run for #[test]s in the main library, not anything under the tests/ directory, examples/, or benches/.

It would be nice to expand to cover them too.

Support the `.eh_frame` augmentation for `.debug_frame`

It's basically the same but there is an augmentation string, a couple extra fields, and CIE IDs are position relative instead of offsets into the section (I think).

Move unit tests out of parser.rs when possible

A lot of the unit tests in parser.rs are testing non-public helper parser functions, so they can't move out or they would lose access to the non-public parser functions. However, for the tests that are only using public APIs, we should move them out to tests/some_test.rs.

ArangeParser doesn't calculate first entry offset correctly

The standard says it has to be aligned to a multiple of the tuple size. This accounts for the weirdness in parse_uN_as_u64.

Implement support for CFI unwinding information

Section 6.4 of the DWARF 4 standard.

TODO:

#112: Be robust against overflow / casting outside of target type's range
#113: Support .eh_frame augmentation
#114: Benches
#115: Self-parse integration test (requires the .eh_frame augmentation)
#116: Output this info in dwarfdump.rs
#117: A single, orchestrating DebugFrame::unwind_info_for_address(&self, ctx: &mut UninitializedUnwindContext, address: u64) -> UnwindTableRow method (for folks who don't have any kind of CIE/FDE caching or anything like that)

DW_FORM_ref_sig8 should not be a .debug_types offset

DW_FORM_ref_sig8 is a type signature, but parse_attribute converts it to a DebugTypesOffset.

Need a method to obtain the abbreviations for a CompilationUnit

Should be able to replace https://github.com/philipc/rust-dwarf/blob/master/benches/bench.rs#L48-L50 with
let abbrevs = unit.abbreviations(&debug_abbrev);
or
let abbrevs = debug_abbrev.abbreviations(unit.debug_abbrev_offset());
(not sure which way is best).

Implement SiblingEntriesIter on top of EntriesCursor

I imagine this would best be exposed via DebuggingInformationEntry::children(&self) -> SiblingEntriesIter where the siblings are the original entry's first child and its siblings.

Should the parser be generic over anything that implements `std::io::Read`?

Right now, gimli parses &[u8] slices, which means that the DWARF section being parsed needs to be completely in memory. Will this be a problem in practice? Is it worth the extra implementation and API complexity to make the input any generic std::io::Read type? Might need to also require std::io::Seek for following DW_AT_sibling references.

@tromey @jimblandy: can I lean on your experiences with GDB for guidance?

cc @philipc

Figure out how to share object loading between example programs

Right now they're copy pasta. Not sure if we can define a lib crate in examples and share it between the two binaries, but that would be ideal. Otherwise, maybe we should pull this stuff out to its own crate proper? I think @jvns has a copy of it, too...

cargo test fails to link on OS X

godot2:gimli jdm$ cargo test
multirust: a new version of 'nightly' is available. run `multirust update nightly` to install it
 Downloading mach_o v0.1.1
 Downloading mach_o_sys v0.1.1
   Compiling mach_o_sys v0.1.1
   Compiling mach_o v0.1.1
   Compiling gimli v0.3.0 (file:///Users/jdm/src/gimli)
error: linking with `cc` failed: exit code: 1
note: "cc" "-m64" "-L" "/Users/jdm/.multirust/toolchains/nightly/lib/rustlib/x86_64-apple-darwin/lib" "/Users/jdm/src/gimli/target/debug/examples/dwarfdump.0.o" "-o" "/Users/jdm/src/gimli/target/debug/examples/dwarfdump" "-Wl,-dead_strip" "-nodefaultlibs" "-L" "/Users/jdm/src/gimli/target/debug" "-L" "/Users/jdm/src/gimli/target/debug/deps" "-L" "/Users/jdm/.multirust/toolchains/nightly/lib/rustlib/x86_64-apple-darwin/lib" "/Users/jdm/src/gimli/target/debug/deps/libmach_o-0cdb1e16b64b3246.rlib" "/Users/jdm/src/gimli/target/debug/libgimli.rlib" "/Users/jdm/src/gimli/target/debug/deps/libbyteorder-e4fc6ea0c49cabcf.rlib" "/Users/jdm/src/gimli/target/debug/deps/libmach_o_sys-e565969333119e7d.rlib" "/Users/jdm/src/gimli/target/debug/deps/libleb128-435299387dd8ef29.rlib" "/Users/jdm/.multirust/toolchains/nightly/lib/rustlib/x86_64-apple-darwin/lib/libstd-8102e29f.rlib" "/Users/jdm/.multirust/toolchains/nightly/lib/rustlib/x86_64-apple-darwin/lib/libcollections-8102e29f.rlib" "/Users/jdm/.multirust/toolchains/nightly/lib/rustlib/x86_64-apple-darwin/lib/libpanic_unwind-8102e29f.rlib" "/Users/jdm/.multirust/toolchains/nightly/lib/rustlib/x86_64-apple-darwin/lib/librustc_unicode-8102e29f.rlib" "/Users/jdm/.multirust/toolchains/nightly/lib/rustlib/x86_64-apple-darwin/lib/libunwind-8102e29f.rlib" "/Users/jdm/.multirust/toolchains/nightly/lib/rustlib/x86_64-apple-darwin/lib/librand-8102e29f.rlib" "/Users/jdm/.multirust/toolchains/nightly/lib/rustlib/x86_64-apple-darwin/lib/liballoc-8102e29f.rlib" "/Users/jdm/.multirust/toolchains/nightly/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-8102e29f.rlib" "/Users/jdm/.multirust/toolchains/nightly/lib/rustlib/x86_64-apple-darwin/lib/liblibc-8102e29f.rlib" "/Users/jdm/.multirust/toolchains/nightly/lib/rustlib/x86_64-apple-darwin/lib/libcore-8102e29f.rlib" "-l" "System" "-l" "pthread" "-l" "c" "-l" "m" "-Wl,-rpath,@loader_path/../../../../../.multirust/toolchains/nightly/lib/rustlib/x86_64-apple-darwin/lib" "-Wl,-rpath,/usr/local/lib/rustlib/x86_64-apple-darwin/lib" "-l" "compiler-rt"
note: Undefined symbols for architecture x86_64:
  "_getsectbynamefromheaderwithswap_64", referenced from:
      mach_o::Header::get_section::hf56a202f8c9bd347 in libmach_o-0cdb1e16b64b3246.rlib(mach_o-0cdb1e16b64b3246.0.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

error: aborting due to previous error
Build failed, waiting for other jobs to finish...
error: Could not compile `gimli`.

Parsing `DW_CFA_set_loc` is wrong

We are currently parsing the address as a uleb, but it should be an address-sized integer and also if the fde's cie defines a non-zero segment size, the address is preceded by a segment.

Implement a atos/addr2line clone example

addr2line should use DIE information

In the absence of .debug_line information, there is still other file and and address information in .debug_info that we can use to give vague information about the address.

Extend `FileEntry::directory` to return the compilation's current directory as `&CStr` instead of `None`

@FitZen suggested:

impl FileEntry {
pub fn directory(&self, header: &LineNumberProgramHeader) -> &'input ffi::CStr;
}

Although we need to handle the index == 0 case, which is supposed to mean the compilation's current directory, which we get from the CU DIE... Maybe it should take that as input, too...

Implement a DWARF expressions interpreter

Section 2.5 of the DWARF 4 standard.

@tromey was showing me a really cool way to fuzz this, but I forget the details...

Re-enable coveralls.io

For whatever reason, coveralls.io just stopped running for us a while back, so I removed the badge and all that. The .travis.yml is actually still running coverage stuff, AFAICT. We should figure out how to get the hook setup correctly again.

UnitHeader::size_of_header is invalid for type units

This breaks is_valid_offset, range, etc.

Need to store something in UnitHeader (eg the header size, or the offset of the first entry), and change size_of_header to take &self.

Improve performance

gimli is currently about twice as slow as rust-dwarf. Need to figure out why and see if gimli can be improved to the same or better speed.

I'm currently tracking down a performance bug in rust-dwarf (due to making endian generic). It's looking like a codegen bug in rustc, so hopefully what I learn from that will be applicable to gimli too.

Run prettify_attr_value on values returned from Attribute::value()

This is trickier than it should be because Attribute is Endian-less. We should probably fix that, many of the subtypes of AttributeValue need an Endianity to be interpreted correctly.

Consider adding a higher level API on top of DIE parsing/traversal

Something like this:

struct Subprogram {
    ...
}

impl Subprogram {
    pub fn new(die: DebuggingInformationEntry) -> Subprogram {
        assert!(die.tag() == DW_TAG_subprogram);
        Subprogram { ... }
    }

    pub fn name(&self) -> Option<&ffi::CStr> { ... }

    pub fn linkage_name(&self) -> Option<&ffi::CStr> { ... }

    pub fn calling_convention(&self) -> Option<DwCc> { ... }

    pub fn is_pure(&self) -> Option<bool> { ... }

    pub fn is_recursive(&self) -> Option<bool> { ... }

    // Etc...
}

Would ideally be able to become owned, if the user wants to copy the data.

Make examples/dwarfdump.rs's output format match the "real" dwarfdump

CFI evaluation should have robust integer overflow and casting

We do a bunch of unchecked adds and casting between integer types with different ranges right now, and we should do a pass to make it more robust.

meaning of 'code' field in DebuggingInformationEntry is unclear

I was comparing the output of dwarfdump to the output of the dwarfdump example program. Most things match up (if I convert hex numbers to little endian byte arrays)! Hooray!

However! One thing that did not match is the numbers <0x18ee> and <41> (in the output I pasted below)

This number 0x18ee in the dwarfdump output comes from dwarf_die_CU_offset in libdwarf. 41 comes from the code field in DebuggingInformationEntry. These two numbers obviously mean different things. But what does code mean? And how can I get the number I want?

here are the two things I'm looking at:

$ dwarfdump $ruby_file
< 1><0x000018ee>    DW_TAG_structure_type
                      DW_AT_name                  "rb_thread_struct"
                      DW_AT_byte_size             0x000003e8
                      DW_AT_decl_file             0x00000002 /home/bork/Downloads/ruby-2.1.6/vm_core.h
                      DW_AT_decl_line             0x0000020c
                      DW_AT_sibling               <0x00001c9a>

$ ./examples/dwarfdump $ruby_file
        <41> <DW_TAG_structure_type>
            DW_AT_name = "rb_thread_struct"
            DW_AT_byte_size = Data([232, 3])
            DW_AT_decl_file = Data([2])
            DW_AT_decl_line = Data([12, 2])
            DW_AT_sibling = UnitRef(UnitOffset(7322))

Add unit tests for abbreviation parsing

Right now, all the DIE stuff is fairly thoroughly unit tested, but the abbreviations are not. It would be nice to expand the coverage for abbreviation parsing.

Implement support for .debug_aranges

Section 6.1.2 of the DWARF 4 standard.

For lookup by address, a table is maintained in a separate object file section called .debug_aranges. The table consists of sets of variable length entries, each set describing the portion of the program’s address space that is covered by a single compilation unit.

Add CI test coverage on osx

https://docs.travis-ci.com/user/multi-os/

Split up parser.rs into smaller modules

Would generally like to have stuff related to each section in its own module, eg .debug_line stuff is in src/line.rs, .debug_abbrev stuff is in src/abbrev.rs, and .debug_str stuff is in src/str.rs (as of a minute ago).

The catch is that the meaty bits of parser.rs is DIE tree things that apply equally to both .debug_info and .debug_types. Not sure how to best break this down into smaller pieces or where exactly boundaries should lie. Make an entries.rs or die.rs for this shared stuff and then make info.rs and types.rs relatiely little?

Any thoughts or opinions @philipc?

Make iteration pattern consistent

Currently there are two patterns of iteration used across the library:

implementing the Iterator trait with Item=ParseResult (eg, DebugInfo::units / UnitHeadersIter, and DebugTypes::units / TypeUnitHeadersIter
having a BlahIter type that does not implement Iterator, and instead has a next method that returns a ParseResult<Option<Blah>>.

From https://github.com/fitzgen/gimli/pull/37#issuecomment-239650372 it seems that the preferred iteration method is the second one.

I'm mostly interested in consistency, but will say that while I get the argument in the linked comment, I still prefer using Iterator<Item=ParseResult<Blah>>. In addition to the more ergonomic for _ in syntax, it also gets you the ability to do things like:

let units: Vec<_> = try!(debug_info.units().collect());

which is much more straightforward than

let aranges = vec![];
let mut iter = debug_aranges.aranges();
while let Some(arange) = try!(iter.next_arange()) {
    aranges.push(arange);
}

The potential for infinite loops on error can be fixed by having a done flag in the iterator struct, which gets set on the first error, or on successful completion of iteration. This is done in the tar crate, for example: https://github.com/alexcrichton/tar-rs/blob/master/src/archive.rs#L442.

Investigate avoiding copying StateMachineRegisters when executing line number programs

From https://github.com/fitzgen/gimli/pull/27#issuecomment-238742174:

It would be nice to avoid copying the registers for every line; it should be up to the caller to decide if a clone is needed. We could do that by storing the current LineNumberRow in StateMachine, and have execute() operate on the registers in that row, instead of having a separate copy. StateMachine::next() would return a reference to current LineNumberRow. Would need to find some way to defer the reset of discriminator/basic_block/prologue_end/epilogue_begin though.

I just looked into this a little and my conclusion is that we would need something like (wrapping?) std::cell::Ref but with a custom Drop impl to do the resetting.

Not going to dig any further at the moment.

addr2line is slower than the binutils version

By about 60-70% on querying a handful of symbols from libxul. Two things jump out at me.

We spend a lot of time in memset according to perf record (not memcpy, memset)
We're chunking writes in 8KB segments, while binutils does 8MB segments. So we make 120000 read syscalls instead of binutil's ~200 to load libxul.

Implement a DfsEntiesIter which yields items of (dfs_depth, DIE)

I imagine that this would be exposed on the various unit types: FooUnit::dfs_entries(&self) -> DfsEntriesIter.

Could also have another type of DFS iterator that maintains the stack of parents for the current entry, yielding iteration items like: (&Vec<DIE>, DIE). Wouldn't want to impose the cost of a vec on users who didn't want it though, so this shouldn't be the only/default option.

Implement support for line number information

Section 6.2 of the DWARF 4 standard.

Add proper support for different kinds of units

Right now only CompilationUnits are properly supported in the library:

the way EntriesCursor is written, it only works with them
We only have a CompilationUnitsIter not a TypeUnitsIter etc...

We should fix this.