[llvm] Aggregate errors from llvm-dwarfutil --verify (PR #79648)

[David Blaikie via llvm-commits]

dwblaikie wrote:

> > > The amount and format of output from `llvm-dwarfutil --verify` makes it quite difficult to know if a change to a tool that produces or modifies DWARF is causing new problems, or is fixing existing problems.
> > 
> > 
> > The way `dsymutil` solves this problem is by having different verification modes.
> > ```
> >   --verify-dwarf <verification mode>
> >                           Run the DWARF verifier on the input and/or output. Valid options are 'none, 'input', 'output', 'all' or 'auto' which runs the output verifier only if input verification passed.
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > Most of the time, invalid DWARF in means invalid DWARF out.
> > > This diff adds a categorized summary of issues found by the DWARF verifier, on by default, at the bottom of the error output.
> > 
> > 
> > I didn't look at the patch, but from the description I'm not sure how aggregated error output solves this problem.
> > Speaking from experience with `dsymutil`, I don't think you want to have the verifier on by default. It's pretty slow and trades off performance to have better error reporting. For `dsymutil`, I made the `auto` verification mode the default in `assert` builds. It's way too slow to turn on in production.
> 
> `dsymutil` is a DWARF processor. `dwarfdump -verify` only does validation. The problem is that DWARF data appears almost always _slightly_ bad. For example, running llvm-dwarfdump -verify _on_ llvm-dwarfdump on my linux development box spits out over 160MB of log. The error information is both overwhelming, and due to the details necessary for diagnosis, nearly impossible to "diff". So, for a tool like Bolt, they can't easily know if they've done something horribly wrong with DWARF data, or if they just moved the errors around. With an error summary, they can figure out what things they might have made worse, what new errors they may have caused, and potentially also identified problems that came from the compiler.
> 
> BTW: Here's the bottom of that --verify log. 123 ranges aren't contained by parent ranges. I hope to improve the diagnostics so the output is a bit more opinionated/informative. I believe that overlapping DW_AT_ranges, for example, just aren't that big of a deal...
> 
> ```
> error: Aggregated error counts:
> error: DIE address ranges are not contained by parent ranges occurred 123 time(s).
> error: DIE has overlapping DW_AT_ranges occurred 119212 time(s).
> error: DIEs have overlapping address ranges occurred 118323 time(s).
> Errors detected.
> ```

These are mostly bugs that should be fixed in the verifier related to address tombstoning. (three CUs with a copy of an inline function - one gets picked, the other two get marked as "dead" usually by setting the starting address to 0 (depends on the linker) and then you have two CUs with functions that start at 0, so they're "overlapping" - or, if the inline functions happen to be truly identical, both CUs might point to the one copy, again, overlapping)

It might just not be the most useful tool to use for what you're trying to do without further work to fix these false positives.

https://github.com/llvm/llvm-project/pull/79648