[PATCH] D42481: [DebugInfo] Add basic support for DWARF 5 .debug_rnglists dumping

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

In https://reviews.llvm.org/D42481#987601, @jhenderson wrote:

> In https://reviews.llvm.org/D42481#986902, @dblaikie wrote:
>
> > I'm guessing several of these invalid tests could be in one file - only the "length too long" should need to be last in the list, right? ("length too short" is undetectable, isn't it? it'd just appear as though the remaining bytes outside the length were the next entry and that entry would be incorrect in some way (its length, version, etc))
>
>
> The "length too short" test is not undetectable in this instance, because it leaves the .debug_rnglists without an end of list marker, which is invalid.


Sure, but it would be detected as "missing end of list marker" rather than "length too short". I would think we should probably be respecting the length to find the boundaries - rather than assuming the length is wrong and walking further to find the beginning of the next contribution.

> In other cases, you are right, a short length may be undetectable e.g. if the length missed out an entire list of ranges, or the entire payload. The invalid_offset_entries test can't be combined with the too long test, because both effectively result in trying to read more than there is available, in the current code (we don't bother to validate the number of offset entries against the section size, although that is something that could be done - I considered this unnecessary because the DataExtractor class will simply read 0s if it runs off the end of the section).

As developer tools, it might be good for llvm-dwarfdump to provide more precise error messages to ensure debugging is as easy as possible (if it says "hey, there's a zero here" and there's no zero - it just reached the end of the contribution - that could cause some painful mislead debugging)

> I could combine the invalid header case, the short case, and one of the long length or invalid offset cases, but as that leaves one separate case, I feel like the clarity of distinct test cases is better at that point.
> 
>> Also, it might be that we want more fidelity in the dumping, so that we can test the differences in encoding between start+length, start+end, offset+offset, etc?
>> 
>> More or less like I was dabbling with for loc lists here: https://reviews.llvm.org/D36300 you can see how different loc list ranges are dumped differently, explaining how the loc list is structured not just what it means semantically.
> 
> I agree that this would be useful to have, but I felt like this belonged under the "verbose" switch in llvm-dwarfdump. This would be similar to .debug_line, where -debug-line dumps just the interpreted line table, whilst -debug-line -verbose dumps the encoding as well as the interpretation of it.

Fair enough


Repository:
  rL LLVM

https://reviews.llvm.org/D42481