This is an archive of the discontinued LLVM Phabricator instance.

Add line table verification to lldb-dwarfdump --verify. AbandonedPublic
ClosedPublic

Authored by clayborg on May 2 2017, 3:33 PM.

Details

Summary

This patch verifies the .debug_line:

  • verify all addresses in a line table sequence have ascending addresses
  • verify that all line table file indexes are valid

Unit tests added for both cases.

Diff Detail

Event Timeline

clayborg created this revision.May 2 2017, 3:33 PM

David: I took care of all your requests from the previous patch in this one.

Woops, nice copy and paste error in the title. Sorry about that. Phabricator is getting worse for copy and paste these days...

Paul: A future patch will add verification of unique DW_AT_stmt_list values and for verifying that all lines entries are in the CU ranges. I need to get another patch in before I do this as this other patch keeps track of all DW_TAG_subprogram address ranges, CU ranges, and verifies all DW_TAG_lexical_block and DW_TAG_inlined_subroutine are contained in their parents. Once I get that in, I can then verify each row address is found in the CU ranges (if available) and also agains the .debug_aranges (if available).

probinson edited edge metadata.May 2 2017, 3:41 PM

Following up on my comment in the other review:

Can you verify that each CU (that has DW_AT_stmt_list) points to a different place in .debug_line?

That is a good idea. Maybe we emit a warning? I say that because it seems like a good way to save space for type unique style DWARF to share line tables since they only use the line tables for DW_AT_decl_file and DW_AT_call_file. Is it against the DWARF spec to share a line table? Let me know if you think this should be a warning or error.

A type unit can certainly point to the same line table as its CU; but type units are not themselves CUs. (In v4 they are in .debug_types not .debug_info, while in v5 they have a distinct unit-type code, so the verifier can easily tell them apart.) So the uniqueness check should not apply to TUs.

I am hard-pressed to imagine a situation where two CUs could reasonably share a line table. In a split-DWARF package file, there is no actual line table, but sharing the directory/file tables implies a coherent use of file/directory numbers across two CUs, or the packager rewriting the CUs to make them consistent, which is *really* hard to justify.

So, unless somebody can come up with a solid use-case, I'd say it should be an error for two CUs to have the same DW_AT_stmt_list offset. (Maybe this should be in the .debug_info verification instead of the line-table verification, though.)

Paul: A future patch will add verification of unique DW_AT_stmt_list values and for verifying that all lines entries are in the CU ranges. I need to get another patch in before I do this as this other patch keeps track of all DW_TAG_subprogram address ranges, CU ranges, and verifies all DW_TAG_lexical_block and DW_TAG_inlined_subroutine are contained in their parents. Once I get that in, I can then verify each row address is found in the CU ranges (if available) and also agains the .debug_aranges (if available).

Awesome, thanks!

So, unless somebody can come up with a solid use-case, I'd say it should be an error for two CUs to have the same DW_AT_stmt_list offset. (Maybe this should be in the .debug_info verification instead of the line-table verification, though.)

I can add the unique DW_AT_stmt_list to this patch then. I will save the range one for later.

dblaikie accepted this revision.May 2 2017, 3:45 PM
dblaikie added inline comments.
unittests/DebugInfo/DWARF/DWARFDebugInfoTest.cpp
1668–1671

Presumably 'verify' should be const? (& then this parameter can be const as well)

This revision is now accepted and ready to land.May 2 2017, 3:45 PM

Paul: I will submit a follow up patch for the DW_AT_stmt_list not being found multiple times since this patch is accepted.

unittests/DebugInfo/DWARF/DWARFDebugInfoTest.cpp
1671

It shouldn't be const because it can cause all compile units to be parsed, all DIEs in each CU to be parsed, any number of DWARFXXX classes to be created.

This revision was automatically updated to reflect the committed changes.

Paul: I will submit a follow up patch for the DW_AT_stmt_list not being found multiple times since this patch is accepted.

WFM.