[LLVMdev] DWARF 2/3 backwards compatibility?

[Rick Foos]

On 10/18/2012 04:23 PM, Eric Christopher wrote:
>> 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.
>

Fair enough. Bugs against dwarf records were what we ended up with here 
after working it down to what was to be fixed in the compiler.

>> 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.
>
Building on a fine grained signal, a bug or two in GDB Testsuite, might 
not be the most important measure.

>> 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.
>

Agreed

>> 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.
>

OK, that may work. Running GDB Testsuite, I often see a few failures 
that go away the next day.

My concern that an absolute XFAIL measure would slow down the rate of 
development changes. If that becomes a problem it's an easy adjustment 
to fix.

Trend lines are just another way to do the same thing, and yes that is 
easier in Jenkins than buildbot :)

> -eric


-- 
Rick Foos
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation