Page MenuHomePhabricator

[DWARF] Return Error from DWARFDebugArangeSet::extract().

Authored by ikudrin on Dec 25 2019, 4:10 AM.



This helps to detect and report parsing errors better. The patch follows the ideas of LLDB's patches D59370 and D59381.

It adds tests for valid and some invalid cases. More checks and tests to come. Note that the patch fixes validation of the Length field because the value does not include the field itself.

Diff Detail

Event Timeline

ikudrin created this revision.Dec 25 2019, 4:10 AM
dblaikie accepted this revision.Dec 25 2019, 10:24 AM
dblaikie added inline comments.

In a separate patch, might be good to add error handling to stop when the Header length is reached, rather than when the section end is reached.


I'd probably write these ays "x == 0" rather than "!x"


Potentially another error case could be added here (in another patch) in the case where the list is terminated earlier than the Length specified in the header.


Looks like the old code fails if the range list is empty - and maybe the new code deosn't fail in that case? Worth adding a test case? (it actually seems reasonable to me to support it - you could imagine a CU with only type information in it & so no covered addresses, and having an arange entry describing that so the consumer didn't have to go discover it through parsing the CU, etc)

This revision is now accepted and ready to land.Dec 25 2019, 10:24 AM
ikudrin updated this revision to Diff 235420.Dec 27 2019, 8:14 AM
ikudrin edited the summary of this revision. (Show Details)
  • "!x" -> "x == 0";
  • Improved error messages wordings;
  • Added more tests;
  • Fixed checking the value of the Length field.
ikudrin edited the summary of this revision. (Show Details)

Thanks for the suggestions, @dblaikie! I've added D71931 and D71932 with corresponding patches.

dblaikie added inline comments.Dec 27 2019, 11:18 AM

Could this be phrased more specifically - "length exceeds section size" or something like that?


Could this be more specific about what's invalid about the address size ("unsupported address size: 5 (4 and 8 supported)" or the like?)

clayborg added inline comments.Jan 9 2020, 3:19 PM

does "toString()" consume the error?


return error instead of crashing the program


return llvm::Error here?


return an error if Set.extract fails? Seems weird to add error handling to only convert it to bool and ignore the error?


Dump the error if Set.extract() fails?

ikudrin updated this revision to Diff 237651.Jan 13 2020, 6:20 AM
  • Update wordings.
  • Replace most of the lit tests to check error cases with gtest-based ones.
  • Do not silently absorb the error messages.
  • Update existing tests and add new ones to reflect the changes.
ikudrin marked 13 inline comments as done.Jan 13 2020, 6:38 AM
ikudrin added inline comments.

Yes. It uses handleAllErrors() internally.


This just checks for the precondition. Callers are responsible to call the method with valid arguments. Therefore, if this triggers, it should be considered as an internal error and fixed.


As this is just a private helper method for DWARFDebugAranges::generate(), I opted to print the errors here.


Done, but it pulled a lot of changes. Maybe it worth to move all them into a separate patch.

lgtm with Error being returned everywhere now.


do we want {} on this while now?

ikudrin updated this revision to Diff 237913.Jan 14 2020, 3:30 AM
ikudrin marked 2 inline comments as done.
  • Used curly brackets for the while loop in dumping .debug_aranges in DWARFContext::dump().
  • Removed else branch after break.

Thanks, @clayborg!

This revision was automatically updated to reflect the committed changes.
ikudrin marked an inline comment as done.
dblaikie added inline comments.Jan 24 2020, 11:59 PM

Might this eventually want to go in the direction of having fallible errors and errors that can continue, like some of @jhenderson 's work? Should we come up with a consistent strategy for this sort of thing as it seems we've developed a few different error handling parsing schemes at this point.

jhenderson added inline comments.Jan 27 2020, 1:34 AM

Yeah, we should a) be consistent (though I don't mind specifically what we standardise on) and b) avoid printing such low-level errors in a library, as it makes things hard for clients. See my lightning talk on the subject that was inspired by my debug line error handling work some time ago: