[PATCH] D72155: [DebugInfo] Make incorrect debug line extended opcode length non-fatal

[Paul Robinson via Phabricator via llvm-commits]

probinson added a comment.

In D72155#1827856 <https://reviews.llvm.org/D72155#1827856>, @dblaikie wrote:

> In D72155#1813778 <https://reviews.llvm.org/D72155#1813778>, @jhenderson wrote:
>
> > In D72155#1813355 <https://reviews.llvm.org/D72155#1813355>, @dblaikie wrote:
> >
> > > Out of curiosity: what's your broader goal with this work? (it'll help understand what's in-scope and out of scope, and better understand the framing when reviewing changes)
> >
> >
> > There's two parts to this:
> >
> > 1. Making it easier for consumers to continue and try to do something with slightly bad output. One of the problems with using the unrecoverable errors is that it prevents people even trying to iterate over later tables.
> > 2. (this one's not specific to this patch, but some other patches in this area I've been doing are related): we have some local code that uses the DebugInfo library to read a line table. In order for this code to be sound, we need to make sure the line table makes sense. The parser in its current state doesn't pick up on a number of bad situations, so we added some local patches to detect these other errors (local because we didn't have time at that point to try to push them into the open source). We'd like to now get these into the opensource library, to avoid merge conflicts.
>
>
> Ah, OK - thanks for the context! (out of curiosity, though not necessary, who is "we"?)


"We" is Sony, here.  James is part of our binutils/linker team.  We have local linker patches to edit the line table in response to GC'ing functions.  Also doing other fixups to alert the debugger to GC'd functions, but the part where we actually parse something is for the line table.

> So you'd like/are working on making libDebugInfoDWARF more pedantic/precise/detect more errors? Specifically only for the line table? Do you have any interest in adding fuzz testing for this, or are your needs less severe than would justify fuzzing?

Mostly we care about dealing with a possibly malformed/corrupt line-number program for one CU, and soldiering on to the next one.  The middle of a user's edit/build/debug cycle is not really the optimal time to abort and whine about a malformed lump of debug info.
I don't know if the linker team has contemplated fuzzing in this area.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72155