This is an archive of the discontinued LLVM Phabricator instance.

[dwarfdump] Resolve also variable specifications/abstract_origins.
ClosedPublic

Authored by friss on Oct 6 2014, 8:30 AM.

Details

Summary

DW_AT_specification and DW_AT_abstract_origin resolving was only performed
on subroutine DIEs because it used the getSubroutineName method. Introduce
a more generic getName() and use it to dump the reference attributes.

Testcases have been updated to check the printed names instead of the offsets
except when the name could be ambiguous.

I implemented getName in a way that allowed to replicate exactly the current
getSubroutineName behavior (checking that each DIE in the reference chain is
a subroutine DIE). It could be made a bit simpler if getSubroutineName
only checked that the root DIE is a subroutine DIE and then called a generic
getName() afterwards.

I can of course commit this in 2 patches, 1 for the getName addition and another
for the use in dump().

Diff Detail

Repository
rL LLVM

Event Timeline

friss updated this revision to Diff 14454.Oct 6 2014, 8:30 AM
friss retitled this revision from to [dwarfdump] Resolve also variable specifications/abstract_origins..
friss added reviewers: dblaikie, samsonov.
friss updated this object.
friss added a subscriber: Unknown Object (MLST).
samsonov added inline comments.Oct 6 2014, 1:44 PM
lib/DebugInfo/DWARFDebugInfoEntry.h
139 ↗(On Diff #14454)

DILineInfoSpecifier::FunctionNameKind looks kind of weird here. Maybe, you should just add a custom enum that would set the kind of name you want to fetch from the DIE (in this way, you might never need to handle FunctionNameKind::None, for instance). Why do you need a SearchOnlySubroutine argument? I don't think a suprogram DIE can refer to a variable DIE via DW_AT_specification attribute.

friss added inline comments.Oct 9 2014, 9:26 AM
lib/DebugInfo/DWARFDebugInfoEntry.h
139 ↗(On Diff #14454)

FunctionNameKind is part of the public DebugInfo interface. I'm not that fond of adding another enum with a very similar meaning (just leaving the None out). How about I move FunctionNameKind out of DILineInfoSpecifier and rename it to something like DINameKind ? I'll still have to deal with the None case, but at least the type passed to getName would be a bit more sensical.

I put the SearchOnlySubroutine parameter to preserve the exact semantic of the getSubroutineName method which checks the type of DIE at each recursive invocation. As said in the patch log, I can remove that parameter and have the DIE type check be done only on the root search DIE (I'd find this nicer myself).

If I don't here any opposition to the above, I'll resubmit with these changes.

friss updated this revision to Diff 14685.Oct 9 2014, 4:03 PM

Address review comments:

  • Introduce DINameKind instead of using the FunctionNameKind type also for variables.
  • Remove the SearchOnlySubroutines parameter to getName and check only if the search root is a subroutine DIE in getSubroutineName.
samsonov accepted this revision.Oct 9 2014, 6:28 PM
samsonov edited edge metadata.

Cool, that looks much cleaner now. Feel free to submit this, and get rid of getSubroutineName() afterwards. It seems to only be used in two places DWARFContext methods. We may just call getName() there and assert that we're in fact calling it on subroutine DIE. Thanks!

lib/DebugInfo/DWARFDebugInfoEntry.h
130 ↗(On Diff #14685)

typo: s/sepcifiaction/specification

This revision is now accepted and ready to land.Oct 9 2014, 6:28 PM
friss closed this revision.Oct 10 2014, 9:01 AM
friss updated this revision to Diff 14734.

Closed by commit rL219506 (authored by @friss).