This is an archive of the discontinued LLVM Phabricator instance.

Add DWARFFormValue::getAsSignedConstant().
Needs ReviewPublic

Authored by friss on Oct 6 2014, 12:13 PM.

Details

Reviewers
dblaikie
Summary

This will be used to dump some attributes in a natural (decimal) form.

It's not easy to come up with some code that would generate signed entities
in all the supported forms, thus I'm adding a unittest for the functionality.
Most of the test is actually boilerplate dummy objects that are required to
parse a DWARFFormValue.

Diff Detail

Event Timeline

friss updated this revision to Diff 14469.Oct 6 2014, 12:13 PM
friss retitled this revision from to Add DWARFFormValue::getAsSignedConstant()..
friss added a reviewer: dblaikie.
friss updated this object.
friss added a subscriber: Unknown Object (MLST).
dblaikie added inline comments.Oct 6 2014, 1:01 PM
lib/DebugInfo/DWARFFormValue.cpp
554

hmm - why is udata considered "not signed". It's specifically saying that the value is positive, so should be returned successfully that way, no?

Arguable, I suppose - but I wouldn't put it past implementations to return positive data in _udata to reduce the number of bytes needed to encode it.

unittests/DebugInfo/DWARFFormValueTest.cpp
103

Does this need tests for any other cases? (these tests would all pass with "getAsSignedConstant()" implemented as a single "return -1")

friss added inline comments.Oct 6 2014, 1:23 PM
lib/DebugInfo/DWARFFormValue.cpp
554

Right. This check wasn't there at first and I added it to prevent issues with values > LONG_MAX being returned as negative numbers. Given how we'll use the method this isn't really an issue.

Note that getAsUnsignedConstant rejects FORM_sdata. It has more reasons to do so, but along the same line of thought, it should maybe return a value if he sdata is in fact positive?

unittests/DebugInfo/DWARFFormValueTest.cpp
103

My main concern was to check that I got the sign extension right for all the FORM_data*. Some other cases can of course be added. Do you have any specific limit tests in mind that would be interesting, or just adding a few positive and negative values to the test would do it for you?

dblaikie added inline comments.Oct 6 2014, 1:36 PM
lib/DebugInfo/DWARFFormValue.cpp
554

I believe the right thing would be for the value to be printed as signed/unsigned based on udata/sdata - or based on context (form kind, etc) if it's dataN. Not sure how convenient that is to implement.

unittests/DebugInfo/DWARFFormValueTest.cpp
103

Yeah, I'd probably just try testing a few other values (potentially replacing the 4 values tested here with more variety - or at least some values in the middle of negatives/positive values, etc)... but maybe it doesn't matter. Up to you.

samsonov added inline comments.
unittests/DebugInfo/DWARFFormValueTest.cpp
10

Unittests may only include headers from include/llvm (i.e., public headers). If we want to add unittests that instantiate DWARFContext, we should make corresponding header public.

friss added inline comments.Oct 6 2014, 2:53 PM
lib/DebugInfo/DWARFFormValue.cpp
554

But here the question isn't even about printing, but only about accepting udata in getAsSignedConstant() and sdata in getAsUnsignedConstant(). Would you prefer the values to be accepted if they fit into the output range and return None otherwise?

unittests/DebugInfo/DWARFFormValueTest.cpp
10

I was actually wondering about this, but I found one prior example of including ../lib/. I'm not sure what the best way forward is for this, if we make the Context public, then everything gets public. Not that I'm opposed to that, it would make some of my planned work easier, and I might propose that in the near future.

What would people think about making the whole DWARF stuff a pubilc interface to libDebugInfo ? (Note that right now this is just to get some testing for this very small feature added just to be able to print AT_lower_bound as a signed decimal... I was already embarrassed by the amount of Dummy* instantiations to get my small test running, but getting the whole interface made public just for that seems a bit too much, doesn't it?)

dblaikie added inline comments.Oct 6 2014, 3:10 PM
lib/DebugInfo/DWARFFormValue.cpp
554

Well, except that getAs(Un)signedConstant is used for dumping (it's also used for other stuff - like getting indexes into the file table... - anything else?).

I think it'd be perfectly reasonable if someone used DW_FORM_sdata for DW_AT_decl_line, to print the value appropriately signed, rather than printing hex bytes. Seems like a good/legible thing to do, even if the input is nonsense.

samsonov added inline comments.Oct 7 2014, 6:23 PM
unittests/DebugInfo/DWARFFormValueTest.cpp
10

I don't really know. Certainly, this set up is an overkill for a small unit test you have. Testing isolated components of DWARF parser are hard because of all the relationship between various sections. However, we can expose DWARFContext.h in public headers somewhere under include/llvm/DebugInfo/DWARF, then create a DWARFTestContext in unittests/, and reuse it in various unit tests. I'm not sure if it would be convenient, or we'd actually need that many unit tests.

friss added inline comments.Oct 9 2014, 2:18 PM
unittests/DebugInfo/DWARFFormValueTest.cpp
10

But if we put DWARFContext.h in the public headers, we have to put (nearly) everything else. Just look at the list of includes at the beginning of DWARFContext.h.

samsonov added inline comments.Oct 9 2014, 6:31 PM
unittests/DebugInfo/DWARFFormValueTest.cpp
10

Sure, I understand this and therefore feel reluctant about this shift. We can do this, but only if it allows us to write a lot of good and helpful unit-tests. I don't yet see how unit-testing a DWARF parser routines can be made easily.