This is an archive of the discontinued LLVM Phabricator instance.

[DebugInfo][NFCI] Add unittest for DWARFAbbreviationDeclarationSet
ClosedPublic

Authored by bulbazord on May 19 2023, 2:49 PM.

Details

Summary

The classes relevant to DWARFDebugAbbrev do not have any unittests
verifying their behavior. Seeing as there is not much error handling
around these classes right now, I want to add some testing as I plan on
making changes to these classes in the near future.

Diff Detail

Event Timeline

bulbazord created this revision.May 19 2023, 2:49 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 19 2023, 2:49 PM
bulbazord requested review of this revision.May 19 2023, 2:49 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 19 2023, 2:49 PM
aprantl accepted this revision.May 19 2023, 3:00 PM
aprantl added a project: debug-info.

That sounds like a good idea!

This revision is now accepted and ready to land.May 19 2023, 3:00 PM

Thanks for the tests - always useful. I've got a couple of comments/suggestions for you.

llvm/unittests/DebugInfo/DWARF/DWARFDebugAbbrevTest.cpp
26

You don't necessarily need this in this patch in isolation, but the patterns you're using to define your abbrevs are likely to be fairly repetitive. I'm assuming you're going to add new unit tests to test the error handling? If so, you may want to look at adding one or more basic generator functions to factor out the test setup (and in which case you may want to do it as part of this patch, or a prerequisite patch). We have similar stuff for the, admittedly more complex, debug info and debug line sections IIRC.

45

I'm not convinced by using sizeof(void *) for the address size, rather than hard-coding values of 4 and 8: the address size is the size of the address in the section data. This is independent of the machine that the test code is built on (i.e. a 32-bit machine should be able to read 64-bit addresses and vice versa).

If it's irrelevant to the test, then hard coding in a value of 4 or 8 is fine. Otherwise, you should test with both 4 and 8-byte addreses.

53

I think the LLVM policy on auto implies this shouldn't be auto, since it's not obvious what the actual type is if you aren't familiar with the interface.

bulbazord added inline comments.May 22 2023, 9:57 AM
llvm/unittests/DebugInfo/DWARF/DWARFDebugAbbrevTest.cpp
26

Yes, I'll be adding more tests, so yanking the setup into a separate function is appropriate. It probably does not need to be very complex though. I'll do so in this patch. Thanks for the suggestion.

45

It is indeed irrelevant to the to the test. I'll hardcode 8.

  • Yank common setup into its own function
  • sizeof(void *) -> sizeof(uint64_t)
  • Don't use auto where confusing
bulbazord marked 3 inline comments as done.May 22 2023, 10:14 AM

It would have been better to wait until I'd had a chance to review your latest updates, as there are a few (admittedly minor) points I'd have picked up on that now need you to go and update the in-tree code. I'm also adding a note that I haven't reviewed the coverage of these tests, just the general approach and style.

llvm/unittests/DebugInfo/DWARF/DWARFDebugAbbrevTest.cpp
24
59

Comments should be full sentences with correct punctuation (https://llvm.org/docs/CodingStandards.html#commenting).

64

If the purpose of this check is to ensure that a valid pointer has come back, this should be ASSERT_TRUE, to prevent the test from continuing and crashing if it isn't. Same goes for a few other cases throughout the tests.

90

Same comment as above.

It would have been better to wait until I'd had a chance to review your latest updates, as there are a few (admittedly minor) points I'd have picked up on that now need you to go and update the in-tree code. I'm also adding a note that I haven't reviewed the coverage of these tests, just the general approach and style.

Apologies, I was too eager to land this. I've uploaded a new phabricator diff to address your comments. We can continue iterating there, sorry about this. D151233