This is an archive of the discontinued LLVM Phabricator instance.

[DWARFv5] Update definitions to match published spec
ClosedPublic

Authored by probinson on Mar 6 2017, 12:01 PM.

Details

Summary

Some late additions to DWARF v5 were not in Dwarf.def; also one form was redefined.
Add the new cases to relevant switches in different parts of LLVM.
Replace DW_FORM_ref_sup with DW_FORM_ref_sup[4,8].

I did not add support for DW_FORM_strx3 or DW_FORM_addrx3 other than defining the constants. We don't have any infrastructure to support these.

Diff Detail

Repository
rL LLVM

Event Timeline

probinson created this revision.Mar 6 2017, 12:01 PM
aprantl accepted this revision.Mar 6 2017, 12:36 PM

Thanks.

include/llvm/Support/Dwarf.def
167 ↗(On Diff #90729)

Comment: versus Comment.?

This revision is now accepted and ready to land.Mar 6 2017, 12:36 PM
probinson marked an inline comment as done.Mar 6 2017, 2:12 PM

beanz got his in first, so the DWARFEmitter.cpp changes move to DWARFVisitor.cpp. I'm rebuilding to make sure I didn't make any new typos, then will commit.

include/llvm/Support/Dwarf.def
167 ↗(On Diff #90729)

Good point.

This revision was automatically updated to reflect the committed changes.
probinson marked an inline comment as done.

Seem like a lot of the Dwarf.def macros could use an extra "version" parameter. Might help code to verify that certain tags, attributes, forms, or more are valid for the current DWARF version.

llvm/trunk/include/llvm/Support/Dwarf.def
142

might be nice at some point to make HANDLE_DW_TAG take a 3rd parameter that is the DWARF version that it is introduced in:

HANDLE_DW_TAG(0x0035, volatile_type, 2)
HANDLE_DW_TAG(0x0036, dwarf_procedure, 3)

Then code could actually enforce the validity of the DWARF tag for the current DWARF version.

243

Might be nice to include the DWARF version in the HANDLE_DW_AT macro as well?

406

Might be nice to include the DWARF version in the HANDLE_DW_FORM macro as well?

Seem like a lot of the Dwarf.def macros could use an extra "version" parameter. Might help code to verify that certain tags, attributes, forms, or more are valid for the current DWARF version.

I am definitely moving in the direction of version checking for forms. Version checking is not so important for other things, as in general anything the consumer doesn't understand can be skipped without having the world explode. But if a consumer doesn't understand a form, the entire section is toast.

The reason I bring up the version is we want a "llvm-dwarfdump --verify" eventually and this might help to provide warnings like:

warning: using DWARF 5 tag in DWARF 4

for DW_TAG values that are in the non-user range.

Ah. I had been thinking more in terms of defining constants like DW_TAG_hi_v4 and doing range checks. That lets you not have to assign arbitrary version numbers to the vendor extensions.