This is an archive of the discontinued LLVM Phabricator instance.

DWARFVerifier: Check "completeness" of .debug_names section
ClosedPublic

Authored by labath on May 8 2018, 8:22 AM.

Details

Summary

This patch implements a check which makes sure all entries required by
the DWARF v5 specification are present in the Name Index. The algorithm
tries to follow the wording of Section 6.1.1.1 of the spec as closely as
possible.

The main deviation from it is that instead of a whitelist-based approach
in the spec "The name index must contain an entry for each debugging
information entry that defines a named subprogram, label, variable,
type, or namespace" I chose a blacklist-based one, where I consider
everything to be "in" and then remove the entries that don't make sense.
I did this because it has more potential for catching interesting cases
and the above is a bit vague (it uses plain words like "variable" and
"subprogram", but the rest of the section speaks about specific TAGs).

This approach has raised some interesting questions, the main one being
whether enumerator values should be indexed. The consensus seems to be
that they should, although it does not follow from section 6.1.1.1.
For the time being I made the verifier ignore these, as LLVM does not do
this yet, and I wanted to get a clean run when verifying generated debug
info.

Another interesting case was the DW_TAG_imported_declaration. It was not
immediately clear to me whether this should go in or not, but currently
it is not indexed, and (unlike the enumerators) in does not seem to cause
problems for LLDB, so I've also ignored it.

Diff Detail

Repository
rL LLVM

Event Timeline

labath created this revision.May 8 2018, 8:22 AM

How expensive is this check when running it on a program the size of clang?

labath added a comment.May 8 2018, 9:48 AM

How expensive is this check when running it on a program the size of clang?

It is significantly faster than the verification we do for .debug_info. .debug_names took 85 seconds for me, whereas .debug_info is now at 13 minutes and still running (this is with asserts enabled). On a somewhat smaller (but still big) executable the ratio was about 10:1.

aprantl accepted this revision.May 8 2018, 9:58 AM
This revision is now accepted and ready to land.May 8 2018, 9:58 AM
JDevlieghere accepted this revision.May 9 2018, 1:59 AM

LGTM, thanks!

This revision was automatically updated to reflect the committed changes.