[PATCH] D82886: [DebugInfo] Fix a possible crash when reading a malformed .debug_*lists section.

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jul 8 11:10:51 PDT 2020


dblaikie added a comment.

In D82886#2139279 <https://reviews.llvm.org/D82886#2139279>, @ikudrin wrote:

> In D82886#2137907 <https://reviews.llvm.org/D82886#2137907>, @dblaikie wrote:
>
> > Ah, thanks! Would be handy to have a test case for that & perhaps some other way to communicate "end of list" that's a bit more explicit?
>
>
> For my understanding, that is not yet broken, so does not need to be fixed.


I'm not suggesting it needs to be fixed - but that that codepath (the one that returns zero) is untested - so when it was committed, it was committed without test coverage. It'd be good to add test coverage where it is missing like this.

>> Hmm, I'm not sure why this produce the repetition - if length() accurately returned the length that was read rather than zero, then it'd go to the end and stop, right?
> 
> `0xffffffff` is a DWARF64 mark, so than it is read, the library expects to read the next 8 bytes.

Right - but what I mean is if there's only 10 bytes, as in your example - it reads the 4 bytes of DWARF64 mark, then 6 bytes out of the desired 8 - if the length was then reported as 10 (with an error saying the length was garbled/the contents terminated earlier than expected), would that be adequate to no longer need the zero length special case?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D82886/new/

https://reviews.llvm.org/D82886





More information about the llvm-commits mailing list