This is an archive of the discontinued LLVM Phabricator instance.

Emit DWARF3 call frame information when DWARF3+ debug info is requested
ClosedPublic

Authored by olista01 on Jun 5 2014, 1:27 AM.

Details

Reviewers
dblaikie
echristo
Summary

Currently, llvm always emits a DWARF CIE with a version of 1, even when emitting DWARF 3 or 4, which both support CIE version 3. This patch makes it emit the newer CIE version when we are emitting DWARF 3 or 4. This will not reduce compatibility, as we already emit other DWARF3/4 features, and is worth doing as the DWARF3 spec removed some ambiguities in the interpretation of call frame information.

It also fixes a minor bug where the "return address" field of the CIE was encoded as a ULEB128, which is only valid when the CIE version is 3. There are no test changes for this, because (as far as I can tell) none of the platforms that we test have a return address register with a DWARF register number >127.

Diff Detail

Event Timeline

olista01 updated this revision to Diff 10124.Jun 5 2014, 1:27 AM
olista01 retitled this revision from to Emit DWARF3 call frame information when DWARF3+ debug info is requested.
olista01 updated this object.
olista01 edited the test plan for this revision. (Show Details)
olista01 added a reviewer: dblaikie.
olista01 added a subscriber: Unknown Object (MLST).
dblaikie edited edge metadata.Jun 5 2014, 1:54 PM

So - is this just correcting the number to reflect the version we're actually emitting? Should we just hardcode it to the higher number, then?

Are there any other cases of differences between CIE versions other than the one place you fixed in this patch? I'd sort of consider leaving that code to just use "emitIntValue" and assert that the value is small enough, with a comment about the right implementation should the value be larger (and a request to add a test case when that happens). As it stands this code would just do bad things if you used the old CIE version and some target that didn't fit in an int?

Should we just hardcode it to the higher number, then?

We can't do that, because CIE version 3 was only introduced in DWARF3, so we need to fall back to CIE version 1 when emitting DWARF2.

Are there any other cases of differences between CIE versions other than the one place you fixed in this patch?

The only place I can find where we rely on CIE version 3 features in the call frame information is llvm/lib/MC/MCDwarf.cpp:1086, but as far a I can tell it is not possible to represent a negative offset with the DWARF2 call frame instructions.

I'd sort of consider leaving that code to just use "emitIntValue" and assert that the value is small enough, with a comment about the right implementation should the value be larger (and a request to add a test case when that happens). As it stands this code would just do bad things if you used the old CIE version and some target that didn't fit in an int?

I have just re-read the DWARF spec, and the return_address_register field addresses a column in the rule table, which may not correspond to a DWARF register number.

With my patch as it currently is, we can represent columns up to 255 in DWARF2, and up to infinity (2^32 in llvm's implementation) in DWARF3. If we used emitIntValue for DWARF3, we could only represent columns up to 127, register numbers 128-255 would unintentionally consume the next byte (due to the LEB128 encoding), resulting in very invalid DWARF.

Asserting when the value cannot be correctly encoded is a good idea, I'll upload a new patch.

olista01 updated this revision to Diff 10169.Jun 6 2014, 2:40 AM
olista01 edited edge metadata.

Added assertion when DWARF2 cannot represent the return address column

emaste added a subscriber: emaste.Jun 13 2014, 6:57 AM
echristo accepted this revision.Jun 16 2014, 11:26 AM
echristo edited edge metadata.

Not to hijack Dave's review, but looks good to me in general.

-eric

lib/MC/MCDwarf.cpp
1275–1276

Comment on the version that we're adding as 1 for < 3, and 3 for >= 3 would be nice.

1308

I think the general style is "if one half has braces they both do" but I'm not wedded to it.

This revision is now accepted and ready to land.Jun 16 2014, 11:26 AM
olista01 updated this revision to Diff 10540.Jun 18 2014, 2:56 AM
olista01 edited edge metadata.

Comments to explain version numbers, code style changes

olista01 updated this revision to Diff 10542.Jun 18 2014, 2:57 AM

Uploading the correct type of diff this time

Eric: do you want me to wait for Dave, or am I OK to commit this?

I believe that was Eric signing off on this, which is fine.

My main misgiving is that I'd like to see all this range handling built into a reusable device and reused by both asm and source range building... (ie: the range handling in MCDwarf/MCContext and the range handling in DwarfDebug) one day. :/

Oops, rambling about the wrong code review. Only reason I didn't sign off on this one is I know next to nothing about CFI.

olista01 closed this revision.Jun 19 2014, 8:47 AM

Thanks, committed revision 211272.