[llvm-dev] [RFC][DWARF] Handling errors in DWARF .debug_line parsing

[Pavel Labath via llvm-dev]

On 16/12/2019 23:47, David Blaikie via llvm-dev wrote:
> 
> 
> On Mon, Dec 16, 2019 at 2:40 PM Jonas Devlieghere <jonas at devlieghere.com
> <mailto:jonas at devlieghere.com>> wrote:
> 
>     Hey James,
> 
>     This sounds really interesting. A few things that come to mind:
> 
>      - I'm curious what kind of errors you'd be okay with in dump mode but
>     not in consumer mode. From LLDB's perspective, we probably want to
>     extract as much information as possible from a malformed line table,
>     as long as we don't end up lying of course.
>      - I need to take another look at the code, but don't we already have
>     something similar where the consumer can decide how to deal with these
>     kinds of issues? I'm bringing this up because I don't think we really
>     need different parsing modes. I think we need to let the consumer
>     decide what to do with the potential errors. The verifier in dwarfdump
>     would presumably stop after the first error (~strict mode) while the
>     dumper would just move on. Would the parsing modes then be a set of
>     "presets" with regards to how to handle these issues?
>      - I'm in favor of creating these error messages lazily, especially
>     for LLDB where we care about responsiveness. However, that does
>     conflict with the behavior you want for the DWARF verifier. We
>     probably want a way to control this?
> 
> 
> For my part - I'd imagine the verifier would be an aggressive reader of
> DWARF - it'd use the same lazy/high quality error API, but the verifier
> code itself would try to walk all of the parts of the DWARF to manifest
> any lazy error cases, rather than needing any other codepath in the parser.

That would be my ideal setup as well (disclaimer: I work on lldb) --
have the parser provide sufficient information so that the verification
can be done from the "outside".

That is, if the goal is to have stronger verification of generated line
tables -- it's not fully clear (to me) whether that's your main
motivation for adding these checks.

regards,
pavel