Breakpad Linux dumper: Parse the .eh_frame section.

Extend google_breakpad::CFISection with the ability to produce
.eh_frame data. Entry headers have a different format, and pointers
can be encoded in new and fascinating ways.

Extend dwarf2reader::CallFrameInfo to be able to parse either DWARF
CFI or .eh_frame data, as determined by an argument to the
constructor. Cope with variations in header formats, encoded pointers,
and additional data in 'z' augmentation data blocks. Extend the unit
tests appropriately.

Extend dump_syms to look for a .eh_frame section, and if it is
present, find the necessary base addresess and parse its contents.

There's no need for DwarfCFIToModule to check the version numbers; if
CallFrameInfo can parse it, DwarfCFIToModule should be able to handle
it. Adjust tests accordingly.

[jimb]

Here's the main patch for .eh_frame support.  With this, CFI on x86 Linux should
pretty much just work out of the box for most programs.

Note that there's a small amount of per-architecture work needed to support CFI:
the dumper and processor need to know the processor's registers' names, and
which fields and validity bits in the MDRawContextFoo structure the names
correspond to.

I'll work on the Mac dumper next, and then I'll look at the ARM and x86_64 CFI
support.

[mochalatte]

http://breakpad.appspot.com/59002/diff/1/4
File src/common/dwarf/dwarf2reader.cc (right):

http://breakpad.appspot.com/59002/diff/1/4#newcode1873
Line 1873: // was never a version 2 fo CFI data). For .eh_frame, we handle only
s/fo/of/

http://breakpad.appspot.com/59002/diff/1/4#newcode1881
Line 1881: if (cie->version < 1 || 3 < cie->version) {
can you change this to be consistent in terms of "variable op constant"?

http://breakpad.appspot.com/59002/diff/1/4#newcode1897
Line 1897: if (cie->augmentation.empty()) {
how about 
if (!cie->augmentation.empty()) {
   if (cie->augmentation[0] == 'z') { }
   else { }
}

rather than an empty ; block?

http://breakpad.appspot.com/59002/diff/1/4#newcode1953
Line 1953: // the pointer itself.
thanks for the detailed comments
can we make the character literals constants?

http://breakpad.appspot.com/59002/diff/1/4#newcode2298
Line 2298: " 'z' augmentation specifies a pointer encoding for which we have no
base address: 0x%02x\n",
80 chars

http://breakpad.appspot.com/59002/diff/1/5
File src/common/dwarf/dwarf2reader.h (right):

http://breakpad.appspot.com/59002/diff/1/5#newcode638
Line 638: 
keep these one per line according to style guide.
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Constructor_In...

http://breakpad.appspot.com/59002/diff/1/6
File src/common/dwarf/dwarf2reader_cfi_unittest.cc (right):

http://breakpad.appspot.com/59002/diff/1/6#newcode46
Line 46: // "cfitest-TEST", where TEST identifies the particular test.
nice way to support this

http://breakpad.appspot.com/59002/diff/1/7
File src/common/linux/dump_symbols.cc (right):

http://breakpad.appspot.com/59002/diff/1/7#newcode419
Line 419: }
is it worth it attempting to load unwind information from the .eh_frame or
.debug_frame section if, for some reason there was no .stab or .debug_info? i.e.
should this check be moved up before either of the unwind sections are attempted
to be found?

[mochalatte]

LGTM

[jimb]

Committed, r552.

[jimb]

I'm sorry, Neal --- I forgot that there were comments here to be addressed; I
just saw the "LGTM" and went ahead.  Here are replies to the comments; I'll post
a fresh patch to address the comments shortly.

http://breakpad.appspot.com/59002/diff/1/4
File src/common/dwarf/dwarf2reader.cc (right):

http://breakpad.appspot.com/59002/diff/1/4#newcode1873
Line 1873: // was never a version 2 fo CFI data). For .eh_frame, we handle only
On 2010/03/03 22:35:01, mochalatte wrote:
> s/fo/of/

Fixed --- thanks!

http://breakpad.appspot.com/59002/diff/1/4#newcode1881
Line 1881: if (cie->version < 1 || 3 < cie->version) {
On 2010/03/03 22:35:01, mochalatte wrote:
> can you change this to be consistent in terms of "variable op constant"?

I was trying to be consistent with the use of '<', so it looks like a number
line.  But I'll make this change.

http://breakpad.appspot.com/59002/diff/1/4#newcode1897
Line 1897: if (cie->augmentation.empty()) {
Done.  I had a reason for doing it that way, but it doesn't seem so compelling
now.

http://breakpad.appspot.com/59002/diff/1/4#newcode1953
Line 1953: // the pointer itself.
On 2010/03/03 22:35:01, mochalatte wrote:
> thanks for the detailed comments
> can we make the character literals constants?

Okay.

http://breakpad.appspot.com/59002/diff/1/4#newcode2298
Line 2298: " 'z' augmentation specifies a pointer encoding for which we have no
base address: 0x%02x\n",
On 2010/03/03 22:35:01, mochalatte wrote:
> 80 chars

D'oh.

http://breakpad.appspot.com/59002/diff/1/5
File src/common/dwarf/dwarf2reader.h (right):

http://breakpad.appspot.com/59002/diff/1/5#newcode638
Line 638: 
On 2010/03/03 22:35:01, mochalatte wrote:
> keep these one per line according to style guide.
>
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Constructor_In...

I'm happy to do this, but that's not how I read that. It says that if they don't
all fit on the first line, then they should be indented by four spaces, but it
doesn't say that they must be one per line. Doing so would be inconsistent with
the general admonition to conserve vertical space.

http://breakpad.appspot.com/59002/diff/1/7
File src/common/linux/dump_symbols.cc (right):

http://breakpad.appspot.com/59002/diff/1/7#newcode419
Line 419: }
I think we should dump it.  For example, suppose some frames in the stack trace
are in code that was compiled with exceptions enabled, but without debugging
information. As written, this code will generate STACK CFI records, but nothing
else, and I believe the backtrace will list addresses, but we may be able to
walk the stack back into code that does have debug information.