[PATCH] Emit DWARF3 call frame information when DWARF3+ debug info is requested

Oliver Stannard oliver.stannard at arm.com
Fri Jun 6 02:38:31 PDT 2014


> 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.

http://reviews.llvm.org/D4027






More information about the llvm-commits mailing list