Support DWARF v3 #57
Assignees
Comments
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I just played around attempting to test DWARF v2 support. It turns out at least on
gcc, that basically implies usage of extensions from later standards. So what ends up happening is that when a binary is created with v2 DWARF, it contains v3 bits and we don't support that.There exists the
-gstrict-dwarfflag, but it seemingly does nothing (?). The bottom line is that supporting DWARF v2 but explicitly not v3 could still mean that we have big gaps in what we actually support.I didn't see the above issue with
clang(it did not appear to be emitting v3 bits when asked for v2), though there we see other issues...The text was updated successfully, but these errors were encountered: