dump_syms spews lots of warnings when processing clang-produced DWARF

[GoogleCodeExporter]

I built Chrome with clang. dump_syms got really noisy, producing lots of lines 
like

/chrome/trunk/src/chrome/../xcodebuild/Release/Google Chrome 
Framework.framework.dSYM/Contents/Resources/DWARF/Google Chrome Framework: the 
DIE at offset 0x37d4566f has a DW_AT_specification attribute referring to the 
die at offset 0x37d45d14, which either was not marked as a declaration, or 
comes later in the file

This is being triggered by src/common/dwarf_cu_to_module.cc 
google_breakpad::DwarfCUToModule::GenericDIEHandler::ProcessAttributeReference(�
��), which comes with this comment:

        // Technically, there's no reason a DW_AT_specification
        // couldn't be a forward reference, but supporting that would
        // be a lot of work (changing to a two-pass structure), and I
        // don't think any producers we care about ever emit such
        // things.

It seems that a producer we care about now emits such things.

I saw this on Mac OS X, but I suspect clang on other platforms would be equally 
affected.

This may have a serious impact on Breakpad’s use with clang-produced binaries.

Original issue reported on code.google.com by mark@chromium.org on 11 Aug 2011 at 4:23

[GoogleCodeExporter]

I'm not going to be able to work on this until September at the earliest. If 
someone else would like to take a shot at it, that'd be great.

We should first verify that it is indeed just forward references --- an 
implementation limitation of ours --- and not bogus specifications --- a bug of 
theirs.

Original comment by jimbla...@gmail.com on 11 Aug 2011 at 7:09

[GoogleCodeExporter]

Not sure if this is useful, but lldb has DWARF reading logic. it seems to be 
here:

http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Symbol/DWARFCallFram
eInfo.h?view=markup
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Symbol/DWARFCallFrameInfo.
cpp?view=markup

Original comment by thakis@chromium.org on 11 Aug 2011 at 4:06

[GoogleCodeExporter]

I came up with an ugly patch that fixes this. http://breakpad.appspot.com/299001

Jim, assuming I clean it up a little bit, would you have time to review it? 
(Before September?)

Original comment by mark@chromium.org on 11 Aug 2011 at 9:56

[GoogleCodeExporter]

Original comment by thakis@chromium.org on 12 Aug 2011 at 8:57

[GoogleCodeExporter]

I think I fixed this on the clang side with 144441.

Original comment by rafael.e...@gmail.com on 12 Nov 2011 at 4:15

[GoogleCodeExporter]

chromium (built with recent clang trunk) still uses the patch 
http://breakpad.appspot.com/299001.

I'm wondering if we still need the patch for mac binary (not only chromium) 
built with gcc (llvm-gcc) or clang in xcode 4.x.

Original comment by ukai@chromium.org on 20 Feb 2013 at 7:10