In the process of pairing up DWARF source lines with the functions they
belong to, the dumper detects and warns about regions of functions that
have no source line information, and vice versa. However, this seems to
occur in real code frequently enough (although not often) that the warnings
may obscure more serious problems.
This patch makes those warnings disabled by default in
DwarfCUToModule::WarningReporter. It does not add a way for the dump_syms
user to enable them.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@566 4c0a9323-5329-0410-9bdc-e9ce6186880e
In order to dump call frame information held in .eh_frame sections, the
dumper needs to know the proper base address to use for pointers encoded
using the DW_EH_PE_textrel encoding. This should be the start of the .text
section. However, due to a cut-and-paste typo, the dumper was supplying the
base address of the ".got" section instead.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@564 4c0a9323-5329-0410-9bdc-e9ce6186880e
This patch allows the Breakpad minidump processor to use data from
STACK CFI records to generate stack traces for the ARM processor.
In the symbol dumper, we need a table mapping DWARF CFI register
numbers to their names: STACK CFI records refer to registers by name.
In the processor, we expand StackwalkerARM::GetCallerFrame to see if
there are STACK CFI records covering the callee, and then use those to
recover the caller's register values.
There's no good reason the ARM walker couldn't use the SimpleCFIWalker
interface declared in cfi_frame_info.h. Unfortunately, that interface
assumes that one can map register names to member pointers of the raw
context type, while MDRawContextARM uses an array to hold the
registers' values: C++ pointer-to-member types can't refer to elements
of member arrays. So we have to write out SimpleCFIWalker::FindCallerRegisters
in StackwalkerARM::GetCallerFrame.
We define enum MDARMRegisterNumbers in minidump_cpu_arm.h, for
convenience in referring to certain ARM registers with dedicated
purposes, like the stack pointer and the PC.
We define validity flags in StackFrameARM for all the registers, since
CFI could theoretically recover any of them. In the same vein, we
expand minidump_stackwalk.cc to print the values of all valid
callee-saves registers in the context --- and use the proper names for
special-purpose registers.
We provide unit tests that give full code and branch coverage (with
minor exceptions). We add a testing interface to StackwalkerARM that
allows us to create context frames that lack some register values.
a=jimblandy, r=mmentovai
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@553 4c0a9323-5329-0410-9bdc-e9ce6186880e
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.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@552 4c0a9323-5329-0410-9bdc-e9ce6186880e
Define a new DWARF parser class, dwarf2reader::CallFrameInfo.
Extend google_breakpad::Module to store and write out 'STACK CFI' records.
Define a new google_breakpad::DwarfCFIToModule class, to accept DWARF
CFI data from the parser and populate a Module with the equivalent
STACK CFI records.
Extend the Linux symbol dumping tool, dump_syms, to use
dwarf2reader::CallFrameInfo, google_breakpad::DwarfCFIToModule, and
google_breakpad::Module to extract DWARF CFI from the executable or
shared library files and write it to the Breakpad symbol file.
Define CFISection, a new class derived from TestAssembler::Section,
for use in creating DWARF CFI data for test cases.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@550 4c0a9323-5329-0410-9bdc-e9ce6186880e
Programs compiled with -ffunction-sections -Wl,--gc-sections may have
SO entries for the start of the compilation unit whose addresses are
zero, even when the compilation unit contains non-omitted functions at
non-zero addresses. The breakpad dumper should not assume that the
compilation unit starting address is always non-zero.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@542 4c0a9323-5329-0410-9bdc-e9ce6186880e
As explained in the code:
Given the right options, the GNU toolchain will omit unreferenced
functions from the final executable. Unfortunately, when it does so,
it does not remove the associated portions of the line number program;
instead, it lets the symbol references in the DW_LNE_set_address
instructions pointing to the now-deleted code resolve to zero. Given
this input, the DWARF line parser will call AddLine with a series of
lines starting at address zero.
Rather than collecting series of lines describing code that is not
there, we should drop them. Since the linker doesn't explicitly
distinguish references to dropped sections from genuine references to
zero, we must use a heuristic. We have chosen:
- If a line starts at address zero, omit it. (On the platforms
breakpad targets, it is extremely unlikely that there will be code
at address zero.)
- If a line starts immediately after an omitted line, omit it too.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@538 4c0a9323-5329-0410-9bdc-e9ce6186880e
Some of the error messages that could be generated in the process of
parsing DWARF debugging information lack terminating newlines.
a=jimblandly, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@536 4c0a9323-5329-0410-9bdc-e9ce6186880e
Any DIE with an DW_AT_inline attribute can be cited by
DW_AT_abstract_origin attributes --- even if the value of the
DW_AT_inline attribute is DW_INL_not_inlined. Thus, we need to set the
inline_ flag on all such DIEs, regardless of the attribute's value.
This allows us to find names in situations like this:
<1><30cf>: Abbrev Number: 57 (DW_TAG_subprogram)
<30d0> DW_AT_specification: <0x3013>
<30d4> DW_AT_decl_file : 1
<30d5> DW_AT_decl_line : 92
<30d6> DW_AT_inline : 0 (not inlined)
<30d7> DW_AT_sibling : <0x30f0>
...
<1><30f5>: Abbrev Number: 59 (DW_TAG_subprogram)
<30f6> DW_AT_abstract_origin: <0x30cf>
<30fa> DW_AT_low_pc : 0x13bc
<30fe> DW_AT_high_pc : 0x13ec
<3102> DW_AT_frame_base : 0x2c (location list)
<3106> DW_AT_sibling : <0x3113>
a=jimblandy, r=nealsid,dmuir
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@526 4c0a9323-5329-0410-9bdc-e9ce6186880e
FindSectionByName will return the first section whose name starts with
NAME, because strncmp stops the comparison once NAME's characters have
been found to match. The comparison stops before the terminating '\0'.
For example, if we search for the section named ".eh_frame", we may
get the section named ".eh_frame_hdr".
Instead, check that the section name section has enough space to store
the complete name with its terminating '\0', and then use strcmp,
which will never examine more than strlen(NAME) + 1 bytes from the
section name section, regardless of its contents, and will require the
terminating '\0' to match as well.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@525 4c0a9323-5329-0410-9bdc-e9ce6186880e
Without this patch, debugging information like the following will produce
FUNC records with no names, because the dumper (correctly) ignores the
DW_TAG_subprogram DIEs that lack DW_AT_low_pc/DW_AT_high_pc attributes, but
won't follow the DW_AT_abstract_origin link from the DIE that does have
code addresses to find its name.
<1><168>: Abbrev Number: 5 (DW_TAG_class_type)
<169> DW_AT_name : Foo
<2><183>: Abbrev Number: 7 (DW_TAG_subprogram)
<185> DW_AT_name : Foo
<18b> DW_AT_declaration : 1
<1><1b7>: Abbrev Number: 12 (DW_TAG_subprogram)
<1b8> DW_AT_specification: <0x183>
<1bc> DW_AT_inline : 2 (declared as inline but ignored)
<1><1dc>: Abbrev Number: 16 (DW_TAG_subprogram)
<1dd> DW_AT_abstract_origin: <0x1b7>
<1e1> DW_AT_low_pc : 0x8048578
<1e5> DW_AT_high_pc : 0x8048588
a=dmuir, r=jimblandy
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@520 4c0a9323-5329-0410-9bdc-e9ce6186880e
Yes, classes are useful. But that doesn't mean that every function has
to gratuitously become a member function. The Google C++ Style Guide
does not require this silliness, since the function is in the
google_breakpad namespace anyway.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@519 4c0a9323-5329-0410-9bdc-e9ce6186880e
This also includes some comments I promised Cary Coutant I'd write
about the appropriateness of processing attributes in EndAttributes
calls.
The Google C++ Style Guide requires each file to have an author notice
and a comment explaining the file's general purpose. For the record, I
don't think putting an author notice on the files is a good idea; it's
odd to have the original author retain prominence even if the file has
been heavily edited by others; the version control system answers this
question more accurately. This is only for Style Guide compliance. The
Apache group decided to discourage author annotations, partially for
these reasons:
http://mail-archives.apache.org/mod_mbox/jakarta-jmeter-dev/200402.mbox/%3C4039F65E.7020406@atg.com%3E
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@518 4c0a9323-5329-0410-9bdc-e9ce6186880e
We've gotten mixed advice from the lawyery types about whether this
matters. But it's easy enough to do.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@517 4c0a9323-5329-0410-9bdc-e9ce6186880e
This extends the ElfArchitecture function to recognize the
architectures it seemed to me that breakpad was most likely to see.
Also: the dumper has historically not provided very helpful error
messages. This patch adds a few that were convenient, but we should do
an audit for this.
a=jimblandy, r=ted.mielczarek
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@507 4c0a9323-5329-0410-9bdc-e9ce6186880e
The Google C++ Style Guide says that members of structures needn't
have names ending in underscores. The structure types in
google_breakpad::Module don't follow this rule.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@505 4c0a9323-5329-0410-9bdc-e9ce6186880e
This adds DWARF support to the Breakpad Linux dumper. This is
implemented as two handler classes: google_breakpad::DwarfCUToModule
accepts data from dwarf2reader::CompilationUnit, and
google_breakpad::DwarfLineToModule accepts data from a
dwarf2reader::LineInfo, each populating a google_breakpad::Module with
the results. Behaviors specific to particular source languages are
handled by instances of a new class, google_breakpad::Language.
An input executable may contain both STABS and DWARF debugging
information: the dumper automatically recognizes what sorts of
information are available, and integrates the data into a single
output file.
All classes have unit tests, providing line and branch coverage of all
interesting code. Unit tests are written using the Google C++ Testing
Framework, and the Google C++ Mocking Framework where appropriate.
a=jimblandy, r=ccoutant
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@497 4c0a9323-5329-0410-9bdc-e9ce6186880e
The stabs reading code in google-breakpad incorrectly assumes that the
stabs data is a single compilation unit. Specifically, it ignores
N_UNDF stabs and assumes that all string indices are relative to the
beginning of the .stabstr section.
This is true when linking with the GNU linker by default, because the
GNU linker optimizes stabs debug info. The gold linker does not do
this optimization. It can be disabled when using the GNU linker with
the --traditional-format command line option.
For more details of the problem, see:
http://sourceware.org/bugzilla/show_bug.cgi?id=10338http://code.google.com/p/google-breakpad/issues/detail?id=359
This patch adds unit tests that reproduce the failure, and fixes the
stabs parser.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@490 4c0a9323-5329-0410-9bdc-e9ce6186880e
Previous patches added unit tests for the STABS parser and the
Breakpad symbol file writer; this adds unit tests for the "dumper"
class that sits between them, receiving data from the parser and
handing it to the writer. So now the whole pathway has coverage.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@467 4c0a9323-5329-0410-9bdc-e9ce6186880e
Adjust Module's interface a bit to facilitate testing:
- Make AssignSourceIds something a client can call --- it's perfectly
well-defined, so this is an okay change.
- Add GetFunctions, GetFiles and FindExistingfile member functions,
which the test harness will use to get results to examine.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@466 4c0a9323-5329-0410-9bdc-e9ce6186880e
A FUNC record's parameter size is also hexadecimal, and all values are
64 bits wide.
A line record's address and size are 64 bits wide.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@465 4c0a9323-5329-0410-9bdc-e9ce6186880e
Building on Ubuntu 9.10 with the distributed compiler (GCC 4.4.1), we get
warnings like the following:
guid_creator.cc:56: warning: dereferencing type-punned pointer will break strict-aliasing rules
It doesn't matter in this case, but there's no crying need to use
reinterpret casts in an endian-dependent way when there are plenty of
well-defined ways to get the same effect.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@447 4c0a9323-5329-0410-9bdc-e9ce6186880e
The test system is based on Google C++ Testing Framework and the
Google C++ Mocking Framework.
This includes a parser that turns human-readable input files ("mock
stabs") into .stab and .stabstr section contents, which we can then
pass to a StabsReader instance, using a handler object written with
GoogleMock. The 'make check' target in src/tools/linux/dump_syms runs
this.
The supplied input file is pretty small, but I've done coverage
testing, and it does cover the parser.
I thought the mock stabs parser would be less elaborate than it turned
out to be. Lesson learned.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@444 4c0a9323-5329-0410-9bdc-e9ce6186880e
If the input passed to a StabsReader instance contains a compilation
unit whose first entry is an N_SO with no name, the parser enters an
infinite loop. Since such entries mark the end of a compilation unit,
ProcessCompilationUnit should skip them.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@443 4c0a9323-5329-0410-9bdc-e9ce6186880e
The StabsHandler class should not provide a fallback definition for
its Warning member function that just throws away warning messages.
It should require the consumer to provide an appropriate definition.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@442 4c0a9323-5329-0410-9bdc-e9ce6186880e
Fix some typos and references to member functions that didn't make the
final cut.
a=jimblandy
r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@381 4c0a9323-5329-0410-9bdc-e9ce6186880e
src/linux/common/module.h defines a new class, google_breakpad::Module,
that can represent the contents of a breakpad symbol file. Module::Write
writes a well-formed symbol file to the given stream.
src/linux/common/dump_symbols.cc can now lose its symbol-file-writing
code, and change DumpStabsHandler to populate a Module object, rather
than the old SymbolInfo/SourceFileInfo/... collection of types.
The code to compute function and line sizes, even in the absence of
reliable size data in STABS, is moved into a new Finalize method of
DumpStabsHandler, which is responsible for completing the Module's
contents.
a=jimblandy
r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@380 4c0a9323-5329-0410-9bdc-e9ce6186880e
With this patch, dump_symbols.cc no longer knows about the details of
the STABS debugging format; that is handled by the StabsReader class.
dump_symbols.cc provides a subclass of StabsHandler that builds
dump_symbols' own representation of the data.
a=jimblandy
r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@378 4c0a9323-5329-0410-9bdc-e9ce6186880e
Because the actual N_FUN strings in the .stabstr section contain type
information after the mangled name, representing this information
using a pointer into .stabstr, while efficient with memory, makes the
FuncInfo data structure STABS-specific: one must know the details of a
STABS N_FUN string's syntax to interpret FuncInfo::name. This patch
removes this STABS dependency from the data structure, and moves us
closer to having an appropriate structure for representing unified
STABS and DWARF data.
a=jimblandy
r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@375 4c0a9323-5329-0410-9bdc-e9ce6186880e
In STABS, if one function's line number information contains an N_SOL
entry to switch to a new source file, then the next function's line
data should pick up in the same source file where the prior function
left off. However, the Linux dumper restarts each function in the
compilation unit's main source file. This patch fixes that, so that
the output attributes the lines in subsequent functions to the correct
source files.
a=jimblandy
r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@373 4c0a9323-5329-0410-9bdc-e9ce6186880e
Let LineInfo structures point directly to their SourceLineInfo
structures, rather than holding the index of the file's name in the
.stabstr section in the early phases, and then later the holding
source_id of the file.
This is another step in the process of moving STABS-specific values
out of the types that represent the breakpad symbol data. When we're
done, the non-STABS structures will be something that we can populate
with both STABS and DWARF data --- or at least it will be more easily
replaced with such.
a=jimblandy
r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@371 4c0a9323-5329-0410-9bdc-e9ce6186880e
