[LLVMdev] DWARF 2/3 backwards compatibility?

Eric Christopher echristo at gmail.com
Thu Oct 18 08:44:00 PDT 2012

On Thu, Oct 18, 2012 at 12:44 AM, Renato Golin <rengolin at systemcall.org> 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).
> 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.

As long as we keep to standard dwarf I'm OK.

> But yeah, focusing on Dwarf 3 would be the best way forward, adding a
> little bit for compatibility (rather than making Dwarf 2 a full-class
> citizen).

Going to disagree here, the state of the art in debuggers isn't
stopping back at dwarf 3 and we shouldn't either. I've already added
some features from dwarf 4 into clang and will be adding dwarf 5
features as we work them through standardization. That said a flag to
delineate dwarf versions is fine and we can work on making sure
features don't bleed over.


More information about the llvm-dev mailing list