[LLVMdev] DWARF 2/3 backwards compatibility?
rfoos at codeaurora.org
Thu Oct 18 15:09:25 PDT 2012
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
> 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.
>> 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
> 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
Trend lines are just another way to do the same thing, and yes that is
easier in Jenkins than buildbot :)
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
More information about the llvm-dev