Support DWARF v5 #42
Assignees
Comments
|
I have a local branch to work on v5. So far, most DIEs are in v4 or earlier versions by default, but I did see some v5 DIEs mixed in the binary. The parser can handle v5 DIEs, although we mark it as We can ignore v5 DIEs as a short-term solution, meaning we will lose v5 information while still using v4 information. It can mitigate the problems of v5. But we definitely need to keep working on v5. |
danielocfb
pushed a commit
to danielocfb/blazesym
that referenced
this issue
May 27, 2023
This change switches the first bit of the DWARF parsing code -- the symbol collection -- over to using the gimli crate. The existing code structure is preserved to minimize churn. For that reason, this change does not attempt to rework the logic inside parse_die_subprogram() and fix any inadequacies there. Using gimli we now gain support for DWARF versions v2, v3, and v5, although that applies only to symbol lookups (because the source code location support is still using the hand rolled DWARF parser). Runtime performance is about the same if our benchmark can be considered representative: Before: > test dwarf::parser::tests::debug_info_parse_single_threaded ... bench: 27,510,100 ns/iter (+/- 487,051) > > test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured; 56 filtered out; finished in 8.30s After: > test dwarf::parser::tests::debug_info_parse_single_threaded ... bench: 28,485,911 ns/iter (+/- 205,511) > > test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured; 54 filtered out; finished in 8.60s Note that these measurements were taken with a slightly adjusted debug_info_parse_single_threaded benchmark, which works on the same copy of the program for the sake of consistency. Also, the numbers were gathered with LTO and -O3 enabled. Lastly, I tried using the gimli::UnitHeader::entries_tree API, but it turned out to be consistently (slightly) slower. Fixes: libbpf#42 Fixes: libbpf#57 Signed-off-by: Daniel Müller <deso@posteo.net>
danielocfb
pushed a commit
to danielocfb/blazesym
that referenced
this issue
May 27, 2023
This change switches the first bit of the DWARF parsing code -- the symbol collection -- over to using the gimli crate. The existing code structure is preserved to minimize churn. For that reason, this change does not attempt to rework the logic inside parse_die_subprogram() and fix any inadequacies there. Using gimli we now gain support for DWARF versions v2, v3, and v5, although that applies only to symbol lookups (because the source code location support is still using the hand rolled DWARF parser). Runtime performance is about the same if our benchmark can be considered representative: Before: > test dwarf::parser::tests::debug_info_parse_single_threaded ... bench: 27,510,100 ns/iter (+/- 487,051) > > test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured; 56 filtered out; finished in 8.30s After: > test dwarf::parser::tests::debug_info_parse_single_threaded ... bench: 28,485,911 ns/iter (+/- 205,511) > > test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured; 54 filtered out; finished in 8.60s Note that these measurements were taken with a slightly adjusted debug_info_parse_single_threaded benchmark, which works on the same copy of the program for the sake of consistency. Also, the numbers were gathered with LTO and -O3 enabled. Lastly, I tried using the gimli::UnitHeader::entries_tree API, but it turned out to be consistently (slightly) slower. Fixes: libbpf#42 Fixes: libbpf#57 Signed-off-by: Daniel Müller <deso@posteo.net>
danielocfb
pushed a commit
to danielocfb/blazesym
that referenced
this issue
May 27, 2023
This change switches the first bit of the DWARF parsing code -- the symbol collection -- over to using the gimli crate. The existing code structure is preserved to minimize churn. For that reason, this change does not attempt to rework the logic inside parse_die_subprogram() and fix any inadequacies there. Using gimli we now gain support for DWARF versions v2, v3, and v5, although that applies only to symbol lookups (because the source code location support is still using the hand rolled DWARF parser). Runtime performance is about the same if our benchmark can be considered representative: Before: > test dwarf::parser::tests::debug_info_parse_single_threaded ... bench: 27,510,100 ns/iter (+/- 487,051) > > test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured; 56 filtered out; finished in 8.30s After: > test dwarf::parser::tests::debug_info_parse_single_threaded ... bench: 28,485,911 ns/iter (+/- 205,511) > > test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured; 54 filtered out; finished in 8.60s Note that these measurements were taken with a slightly adjusted debug_info_parse_single_threaded benchmark, which works on the same copy of the program for the sake of consistency. Also, the numbers were gathered with LTO and -O3 enabled. Lastly, I tried using the gimli::UnitHeader::entries_tree API, but it turned out to be consistently (slightly) slower. Fixes: libbpf#42 Fixes: libbpf#57 Signed-off-by: Daniel Müller <deso@posteo.net>
danielocfb
pushed a commit
to danielocfb/blazesym
that referenced
this issue
May 27, 2023
This change switches the first bit of the DWARF parsing code -- the symbol collection -- over to using the gimli crate. The existing code structure is preserved to minimize churn. For that reason, this change does not attempt to rework the logic inside parse_die_subprogram() and fix any inadequacies there. Using gimli we now gain support for DWARF versions v2, v3, and v5, although that applies only to symbol lookups (because the source code location support is still using the hand rolled DWARF parser). Runtime performance is about the same if our benchmark can be considered representative: Before: > test dwarf::parser::tests::debug_info_parse_single_threaded ... bench: 27,510,100 ns/iter (+/- 487,051) > > test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured; 56 filtered out; finished in 8.30s After: > test dwarf::parser::tests::debug_info_parse_single_threaded ... bench: 28,485,911 ns/iter (+/- 205,511) > > test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured; 54 filtered out; finished in 8.60s Note that these measurements were taken with a slightly adjusted debug_info_parse_single_threaded benchmark, which works on the same copy of the program for the sake of consistency. Also, the numbers were gathered with LTO and -O3 enabled. Lastly, I tried using the gimli::UnitHeader::entries_tree API, but it turned out to be consistently (slightly) slower. Fixes: libbpf#42 Fixes: libbpf#57 Signed-off-by: Daniel Müller <deso@posteo.net>
danielocfb
pushed a commit
to danielocfb/blazesym
that referenced
this issue
May 30, 2023
This change switches the first bit of the DWARF parsing code -- the symbol collection -- over to using the gimli crate. The existing code structure is preserved to minimize churn. For that reason, this change does not attempt to rework the logic inside parse_die_subprogram() and fix any inadequacies there. Using gimli we now gain support for DWARF versions v2, v3, and v5, although that applies only to symbol lookups (because the source code location support is still using the hand rolled DWARF parser). Runtime performance is about the same if our benchmark can be considered representative: Before: > test dwarf::parser::tests::debug_info_parse_single_threaded ... bench: 27,510,100 ns/iter (+/- 487,051) > > test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured; 56 filtered out; finished in 8.30s After: > test dwarf::parser::tests::debug_info_parse_single_threaded ... bench: 28,485,911 ns/iter (+/- 205,511) > > test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured; 54 filtered out; finished in 8.60s Note that these measurements were taken with a slightly adjusted debug_info_parse_single_threaded benchmark, which works on the same copy of the program for the sake of consistency. Also, the numbers were gathered with LTO and -O3 enabled. Lastly, I tried using the gimli::UnitHeader::entries_tree API, but it turned out to be consistently (slightly) slower. Fixes: libbpf#42 Fixes: libbpf#57 Signed-off-by: Daniel Müller <deso@posteo.net>
danielocfb
pushed a commit
to danielocfb/blazesym
that referenced
this issue
May 30, 2023
This change switches the first bit of the DWARF parsing code -- the symbol collection -- over to using the gimli crate. The existing code structure is preserved to minimize churn. For that reason, this change does not attempt to rework the logic inside parse_die_subprogram() and fix any inadequacies there. Using gimli we now gain support for DWARF versions v2, v3, and v5, although that applies only to symbol lookups (because the source code location support is still using the hand rolled DWARF parser). Runtime performance is about the same if our benchmark can be considered representative: Before: > test dwarf::parser::tests::debug_info_parse_single_threaded ... bench: 27,510,100 ns/iter (+/- 487,051) > > test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured; 56 filtered out; finished in 8.30s After: > test dwarf::parser::tests::debug_info_parse_single_threaded ... bench: 28,485,911 ns/iter (+/- 205,511) > > test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured; 54 filtered out; finished in 8.60s Note that these measurements were taken with a slightly adjusted debug_info_parse_single_threaded benchmark, which works on the same copy of the program for the sake of consistency. Also, the numbers were gathered with LTO and -O3 enabled. Lastly, I tried using the gimli::UnitHeader::entries_tree API, but it turned out to be consistently (slightly) slower. Closes: libbpf#42 Closes: libbpf#57 Signed-off-by: Daniel Müller <deso@posteo.net>
danielocfb
pushed a commit
to danielocfb/blazesym
that referenced
this issue
May 31, 2023
This change switches the first bit of the DWARF parsing code -- the symbol collection -- over to using the gimli crate. The existing code structure is preserved to minimize churn. For that reason, this change does not attempt to rework the logic inside parse_die_subprogram() and fix any inadequacies there. Using gimli we now gain support for DWARF versions v2, v3, and v5, although that applies only to symbol lookups (because the source code location support is still using the hand rolled DWARF parser). Runtime performance is about the same if our benchmark can be considered representative: Before: > test dwarf::parser::tests::debug_info_parse_single_threaded ... bench: 27,510,100 ns/iter (+/- 487,051) > > test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured; 56 filtered out; finished in 8.30s After: > test dwarf::parser::tests::debug_info_parse_single_threaded ... bench: 28,485,911 ns/iter (+/- 205,511) > > test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured; 54 filtered out; finished in 8.60s Note that these measurements were taken with a slightly adjusted debug_info_parse_single_threaded benchmark, which works on the same copy of the program for the sake of consistency. Also, the numbers were gathered with LTO and -O3 enabled. Lastly, I tried using the gimli::UnitHeader::entries_tree API, but it turned out to be consistently (slightly) slower. Closes: libbpf#42 Closes: libbpf#57 Signed-off-by: Daniel Müller <deso@posteo.net>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See subject. Seems to be not implemented currently:
blazesym/src/dwarf/debug_info.rs
Line 1040 in 442f295
The text was updated successfully, but these errors were encountered: