[LLVMdev] DWARF 2/3 backwards compatibility?

[Rick Foos]

I'd like to summarize what we've discussed for a moment, and propose a patch
tomorrow. It will clear a problem we have, and provide a way to handle a lot
more of these that will come up as we go to Dwarf 5, and the next GDB.

The framework is a set of GCC like gdwarf[2,3,4,5] flags. I can see cases
where compatibility is 2,3 or 2,3,4, so maybe the flag is a number to allow
<=3 tests, have to sleep on that. This flag must go to the backend. 

Then the patch will change the conditional for DW_FORM_flag_present that
caused the problem back to the old DW_FORM_flag when -gdwarf2 or 3 is set.

In the future, there is a now a place to address compatibility issues that
come up.

----

Monitoring this with GDB Testsuite as Jenkins or Buildbot would be a good
idea. 20K+ tests are difficult to duplicate. 

GDB Testsuite is not easy to run and get stable, but I've been doing it for
a few months now, and it can be done. One advantage with LLVM is that x86
will do a fair job covering the other architectures, and then a small number
of tests to cover the gaps would be all that is needed.

I don't think GDB testsuite should block a commit, it can vary by a few
tests, they rarely if ever all pass 100%. Tracking the results over time can
catch big regressions, as well as the ones that slowly increase the failed
tests.

Cheers,
- rick




-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Robinson, Paul
Sent: Wednesday, October 17, 2012 8:53 PM
To: Eric Christopher; Renato Golin
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] DWARF 2/3 backwards compatibility?

Rick Foos wrote:
> The error we are getting is:
> "Undefined Form Value: 25"
> ...
> DW_FORM_flag_present caused the problem. The old DW_FORM_flag works for
us.

I see this error from GDB 7.0 but GDB 7.2 is okay with it.
Now you know as much as I do.  :-)

Eric Christopher wrote:
> [in reply to what Renato Golin wrote:]
> > With time, you might get to a point where Dwarf is a first-class 
> > citizen and there will be basic compatibility checks in "make check"
> > and a build bot for GDB test suite on some platforms, but to get 
> > there, you'll go through a lot of pain.
> >
> 
> Hopefully not too much. Paul has been helping and I add tests whenever 
> I fix something, but a quality suite is something else. Unfortunately 
> as the biggest consumer debugger testsuites have a tendency to be the 
> primary quality test for debug info.

I have thought that a GDB bot would be a good idea, but then it would be a
specific version of GDB, and opinions differ on what would be the "right"
version.  I suppose any version is better than nothing...

I had a "quality suite" at a previous job; it was the result of many PY of
effort.  It was also debugger-based, which is a mixed blessing; you get a
lot of DWARF-parsing code for free, but then you get a lot of debugger bugs
for free too!  And you don't get to test the DWARF directly, you get to test
how the debugger uses the DWARF. Not really optimal, but still--a whole lot
better than nothing.

> > Dwarf implementation in LLVM, as far as I know, is ad-hoc, so you'll 
> > have to do some refactoring (for good) on the debug emission code.
> 
> I've tried to formally implement a few things, but in general it was 
> ad-hoc for so long this is true.

Yeah, clearly some DWARF 3 bits are creeping in, and more will come.
(I have some UTF-8 work waiting for a chance to be cleaned up and submitted,
for example.  DW_AT_use_UTF8 is a DWARF 3 attribute.) But if some people
really are stuck in DWARF 2 land, we might have to do something intelligent
about it. (I'd rather not, I'd rather have LLVM assert that DWARF 3 is where
it's at.  I mean really, DWARF 3 was published in 2005!)

--paulr

_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev