[LLVMdev] DWARF 2/3 backwards compatibility?

[Eric Christopher]

>
> Take the log file, check out the suite, rerun a failing test, use dwarfdump
> and llvm-dwarfdump, find the "bad" dwarf records produced by the compiler.
>
> All the eventual bugs are about dwarf records, and a gdb testsuite test to
> duplicate.
>

That's not necessarily the case.

> A bad/confused dwarf record fails multiple tests without a way to map a
> failure back to dwarf.
>

I'm not sure what you mean here.


> In the case of clang, all the arch's share the Dwarf processing. So an x86
> run covers a lot more of the dwarf processing than worrying too much about a
> cross compiler run. (But some worry about limiting fixes to regressions from
> a cross-compiled GCC, so have to run that as well)

For what it's worth you're going to miss some aspects since location
information is going to be dependent upon how various instructions are
lowered and could lead to missing/different location information than
would be correct.

> I avoid doing that the XFAIL thing. Plotting all the lines from the summary
> makes more sense, and it's what you see when you run the test manually.
>
> When you move a Fail artificially to Xfail, the plot just has a few V's in
> it where the Fail line drops, and the Xfail line goes up. No new
> information.
>

xfailing tests or some such is a good starting way of detecting
regressions which is one of the advantages of a buildbot like system -
to give quick feedback on changes that make things start failing.
Ideally, of course, we'd like to have a testsuite full of only passing
tests and any failure is an immediate problem as well. As we move
forward on debug information though a good first step is to make sure
with no new regressions as we do work and see the trend line of
failures going down over time.

-eric