[LLVMdev] DWARF 2/3 backwards compatibility?

Robinson, Paul Paul.Robinson at am.sony.com
Thu Oct 18 13:36:05 PDT 2012


Renato Golin wrote:
> On 18 October 2012 02:53, Robinson, Paul <Paul.Robinson at am.sony.com> wrote:
> > 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.
> 
> The trade off also goes in the other direction. If you had a strict
> Dwarf parser green, that would mean next to nothing as to what that
> Dwarf would represent in the debugger(s).

Well, having IR-level testing tells you next to nothing as to what your
program would actually do when you compile and run it.  But it seems 
to me that we have a huge pile of IR-level tests, so _somebody_ must 
think they are useful. :-)

Sure, the acid test is whether the debugger does the right thing. I'm
not saying debugger-based tests are worthless, I'm saying that _just_
having debugger-based tests is not _optimal_.  DWARF-level testing
would let you do things that debugger-based tests would find anywhere
from awkward to impossible.

That said, what's easiest is probably to get some form of GDB bot up
and running, and the benefit is likely to be worth the pain.

> AFAIK, most Dwarf compatible debuggers are also GDB compatible, which
> means that even the idiotic things that GDB does will probably be
> understood by other debuggers.

I don't think what GDB _does_ will be understood by other debuggers. :-)
And the debugger for some of the platforms I have to deal with is
certainly not GDB, so I care more about generating valid DWARF than
I do about getting GDB running smoothly.  I do recognize that the
majority of LLVM targets care more about GDB, though.

Cheers,
--paulr




More information about the llvm-dev mailing list