[LLVMdev] DWARF 2/3 backwards compatibility?

[Jim Grosbach]

All,

I don't really have much to add to the details of the discussion, but it's very cool to see debug-info testing getting some solid discussion and tender loving care.  I'm looking forward to seeing the test suites improve along with the code. Thanks!

-Jim

On Oct 18, 2012, at 3:09 PM, Rick Foos <rfoos at codeaurora.org> wrote:

> 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
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev