I had to remove the dependency from base (was using FilePath and ScopedHandle, replaced them by standard std::wstring and HANDLE). Also removed the logging and the main from the original files.
This will serve as a base for testing breakpad's dump generation. It is kept like this for easier tracking.
Review URL: http://codereview.chromium.org/1964006
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@592 4c0a9323-5329-0410-9bdc-e9ce6186880e
The XCode project file has become encrufted with duplicate Executable
entres and some strange settings. This patch deletes and recreates various
entries to make things neat again. It should have no effect on the
project's visible behavior.
a=jimblandy, r=thestig
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@591 4c0a9323-5329-0410-9bdc-e9ce6186880e
to TestAssembler::Section.
This patch helps the TestAssembler classes generate Mach-O object files for
use as test input.
This patch adds a new AppendCString overloading to TestAssembler::Section
for emitting null-terminated strings in fixed-length buffers, where the
string is truncated and the terminating null character omitted if the
string is too large for the buffer.
The patch includes unit tests for the new AppendCString overloading. It
also provides some for the existing overloading, which had been neglected.
a=jimblandy, r=mark
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@590 4c0a9323-5329-0410-9bdc-e9ce6186880e
Breakpad's Macintosh symbol dumper uses deprecated functions for
dealing with mixed-endianness code. This patch provides an overloaded
function, ByteSwap, that automatically chooses the OSSwap* functions
from <libkern/OSByteOrder.h> appropriate for its argument's
size.
This patch does *not* address warnings in src/common/mac/dump_syms.mm,
because that code is about to be replaced entirely; there's no reason to
bother reviewing a big, detailed patch against it.
a=jimblandy, r=mark
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@589 4c0a9323-5329-0410-9bdc-e9ce6186880e
It's possible to imagine an implementation of google_breakpad::Module in
which calling SetLoadAddress at different times as the Module is populated
would produce different output. For the Mac dumper, we'd like to depend on
its current behavior --- that the load address is subtracted off only when
writing the symbol file, and can be set at any time prior to that.
This patch makes that promise part of Module's contract, and adjusts the
test suite to verify that that promise is met.
a=jimblandy, r=thestig
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@588 4c0a9323-5329-0410-9bdc-e9ce6186880e
This patch addresses two differences between Linux and Macintosh OS X STABS
data:
- StabsReader assumes that the STABS entries follow the conventions for
storing STABS data in object file sections (that is, .stabs and
.stabstr), rather than in the object files's linker symbol table. On Mac
OS X, STABS entries live in the Mach-O file's LC_SYMTAB load command,
along with all the other linker symbols; they are not grouped into units
by N_UNDF entries.
This patch adds a boolean argument to the StabsReader constructor
indicating whether the parser should treat N_UNDF entries as unit
boundaries; this argument should be true on Linux, and false on Mac. The
patch changes src/common/linux/dump_symbols.cc to pass this new argument.
- Mac OS X STABS place SLINE (line number) records immediately before the
FUN record for the function to which they belong, and the values of such
records are absolute, not relative to the function start.
This patch extends the parser to queue up such records and report them to
the handler when we do see the FUN record. The meaning of
StabsHandler::Line remains unchanged; existing handlers do not need to be
adjusted.
This patch also adds unit tests for the new parser behaviors.
a=jimblandy, r=mark
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@587 4c0a9323-5329-0410-9bdc-e9ce6186880e
This patch factors out some of the common code in the StabsReader unit
tests into a fixture class. Pretty mechanical.
a=jimblandy, r=thestig
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@586 4c0a9323-5329-0410-9bdc-e9ce6186880e
An N_FUN stabs with no name is an explicit end-of-function marker, whose
value is the size of the function. This patch changes the stabs reader to
recognize these and use them to compute the function's ending address,
instead of treating them as functions with no names and mysterious
addresses. It also adds appropriate unit tests.
a=jimblandy, r=thestig
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@585 4c0a9323-5329-0410-9bdc-e9ce6186880e
All the other classes which receive debugging data from some sort of parser
and use it to populate a Module have names ending in "ToModule":
DwarfCUToModule, DwarfCFIToModule. Also, DumpStabsHandler doesn't actually
dump anything.
This patch renames the DumpStabsHandler class to StabsToModule, which is
more consistent and descriptive.
a=jimblandy, r=thestig
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@584 4c0a9323-5329-0410-9bdc-e9ce6186880e
StabsReader simply applies a reinterpret_cast to treat the stab entry data
as an array of 'struct nlist' structures, making the parser specific on the
host endianness, word size, and alignment rules. On Mac OS X, a single fat
binary file may contain object files of different ABIs, of which the user
chooses one at run time.
This patch changes the parser to read the data using the google_breakpad::
ByteCursor class, which can handle different endiannesses and word sizes.
The StabsReader constructor now takes arguments indicating the endianness
of the data and the size of each entry's value field. The patch changes
src/common/linux/dump_symbols.cc to pass the new argument.
This patch changes the StabsReader unit tests to use the google_breakpad::
TestAssembler classes to generate test data, rather than reading it from a
file. This makes it easy to generate test data in various endiannesses and
word sizes. It also adds tests for the new parser behaviors.
a=jimblandy, r=thestig
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@583 4c0a9323-5329-0410-9bdc-e9ce6186880e
The ByteBuffer and ByteCursor classes are utility classes for reading
binary files, handling endianness and word size issues in a portable way.
a=jimblandy, r=thestig
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@582 4c0a9323-5329-0410-9bdc-e9ce6186880e
The DumpStabsHandler class creates Module::Function objects as it processes
data from the StabsReader, but waits to add the Functions to the Module
until all parsing is complete and its Finalize member function is called,
so that it can compute line and function end addresses that the STABS data
may have left implicit.
If the DumpStabsHandler is destructed before its Finalize method is called,
it fails to free the Functions it has created, but not yet added to the
Module. (Adding a Function to a Module transfers ownership of the Function
to the Module.)
This adds a destructor to DumpStabsHandler which takes care of freeing any
Functions that it still owns.
a=jimblandy, r=thestig
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@576 4c0a9323-5329-0410-9bdc-e9ce6186880e
At the moment, the mappings from register numbers appearing in DWARF CFI
and .eh_frame exception handling sections to the appropriate
processor-specific names are in src/common/linux/dump_syms.cc. However, the
numberings are (for the most part) the same on all platforms using DWARF,
so there's no reason those tables shouldn't be shared between the Linux and
Mac symbol dumpers.
This patch moves the tables into a nested class of DwarfCFIToModule, so
they the Mac dumper can use them when it is changed to use
DwarfCFIToModule.
a=jimblandy, r=thestig
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@575 4c0a9323-5329-0410-9bdc-e9ce6186880e
The google_breakpad::TestAssembler classes are used in both the processor's
and the Linux dumper's test suites, and will soon be used in the Mac
dumper's tests as well. This patch moves their source files from
src/processor to src/common.
a=jimblandy, r=thestig
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@574 4c0a9323-5329-0410-9bdc-e9ce6186880e
When building with G++ 4.1.2, src/processor/cfi_frame_info.cc fails to
build with the error below. G++ 4.2.1 and later do not seem to report this
problem.
This patch works around the problem by casting stream.tellp() to
std::streamoff before doing the comparison.
src/processor/cfi_frame_info.cc: In member function `std::string google_breakpad::CFIFrameInfo::Serialize() const':
src/processor/cfi_frame_info.cc:105: error: ambiguous overload for `operator!=' in `stream.std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >::<anonymous>.std::basic_ostream<_CharT, _Traits>::tellp [with _CharT = char, _Traits = std::char_traits<char>]() != 0'
src/processor/cfi_frame_info.cc:105: note: candidates are: operator!=(std::streamoff, int) <built-in>
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/postypes.h:143: note: bool std::fpos<_StateT>::operator!=(const std::fpos<_StateT>&) const [with _StateT = __mbstate_t]
a=jimblandy, r=mmentovai
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@572 4c0a9323-5329-0410-9bdc-e9ce6186880e
pdb filenames in crash reports may contain embedded newlines. When
minidump-stackwalk prints these lines, it ends up with:
Module|olek8r4u.dll|6.0.6000.16386|\\xc2\\xeb\\x17\\x04J\\xb6:\\xbaT\\xf3\\xef\\xe8Y\\x90\\x86\\xaa\\xe5\\x16n\\xb1\\x80\\x85\\t\\x12!\\x16\\x0f\\x98\\xf8\\x89\\x16"\\x96\\xd4\\x84\\x88\\xea\\xe3\\r\\r\\x1b\\xca\\x85*^h\\xf5\\xdc\n\\xd9\\xf4}j\\x1d7\\xe39o\\x1f\\xc5\\xc4\\xa6x\\x8ba\\xe8\\xd6K\\x89H\\xe1\\xff\\xe7\\xf5\\xf0Y\\xfd\\xf5\\xdbu\\x0c\\x07\\x86\\xed|29E0B04FCCBE47EB86A6C819E8B89D051|0x00f60000|0x00ff2fff|0\n
Which has an embedded newline and the machine parser can't handle it. This
patch just strips the embedded newline, just as we strip embedded |
separator characters.
a=bsmedberg, r=jimblandy
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@571 4c0a9323-5329-0410-9bdc-e9ce6186880e
The Linux symbol dumper's classes are reasonably portable, and should be
usable for the Mac dumper as well. Move them to src/common, along with
their unit tests. Update #include directives and Makefile.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@567 4c0a9323-5329-0410-9bdc-e9ce6186880e
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
The Linux dumper's Makefile doesn't record the object files' dependence on
header files at all, just because I was too lazy to write them out and knew
I would forget to keep them up to date anyway. But I've wasted too much
time tracking down mysterious segmentation faults and other problems after
changing header files, and I know it's wasted others' time, too.
a=jimblandy, r=nealsid,dmuir
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@563 4c0a9323-5329-0410-9bdc-e9ce6186880e
The comments don't accurately describe what the style guide says.
Regardless of what the style guide says, RTTI seems to make trouble in
practice, because so many people build with it disabled. Since only the
symbol dumper uses RTTI, not the client library, it may be practical for
people to simply enable RTTI for the dumper. Failing that, it may be best
in the long run to violate the style guide and make the code work sans
RTTI.
a=jimblandy, r=mmentovai
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@561 4c0a9323-5329-0410-9bdc-e9ce6186880e
- Use manifest constants for 'z' augmentation letters.
- Fix typos and rearrange some code for legibility.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@560 4c0a9323-5329-0410-9bdc-e9ce6186880e
Breakpad Linux client: Simplify VerifyStackReadWithMultipleThreads unit test.
As written, the VerifyStackReadWithMultipleThreads unit test makes
assumptions about the layout of thread_function's stack frame. As a result,
the test will fail when compiled with some compilers, or built with certain
optimization levels.
As an extension to C++, the GNU compilers allow you to request that a
variable be placed in a specific register. Using this, we can have
thread_function put the thread id in place where the test can find it
reliably.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@559 4c0a9323-5329-0410-9bdc-e9ce6186880e
As written, the VerifyStackReadWithMultipleThreads unit test makes
assumptions about the layout of thread_function's stack frame. As a result,
the test will fail when compiled with some compilers, or built with certain
optimization levels.
As an extension to C++, the GNU compilers allow you to request that a
variable be placed in a specific register. Using this, we can have
thread_function put the thread id in place where the test can find it
reliably.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@558 4c0a9323-5329-0410-9bdc-e9ce6186880e
Having an exception of interest makes the resultant minidumps look just like
crash dumps, in that the processor can identify the "crashing" tread.
This means such minidumps can be classified by the stack signature, in contrast to the current state of things, in which all such dumps get lumped on a single pile.
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@557 4c0a9323-5329-0410-9bdc-e9ce6186880e
This adds support for 'STACK CFI' records (DWARF CFI) to the AMD64
stack walker. This is necessary for the stack trace to include any
frames other than the youngest. Unit tests are included.
a=jimblandy, r=mmentovai
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@554 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
The Linux C++ exception handling data format (.eh_frame) can specify a
number of different encodings for the addresses it contains. This
patch extends dwarf2reader::ByteReader to read pointers encoded in
these ways.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@551 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
Add a CFIFrameInfo class (named for symmetry with WindowsFrameInfo) to
represent the set of STACK CFI rules in effect at a given instruction,
and apply them to a set of register values. Provide a SimpleCFIWalker
class template, to allow the essential CFI code to be shared amongst
the different architectures.
Teach BasicSourceLineResolver to partially parse 'STACK CFI' records,
and produce the set of rules in effect at a given instruction on
demand, by combining the initial rule set and the appropriate rule
deltas in a CFIFrameInfo object.
Adapt StackwalkerX86 and StackFrameX86 to retrieve, store, and apply
CFI stack walking information.
Add validity flags for all the general-purpose registers to
StackFrameX86::ContextValidity.
a=jimblandy, r=mmentovai
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@549 4c0a9323-5329-0410-9bdc-e9ce6186880e
Issue 53001 (http://breakpad.appspot.com/53001) defines the
TestAssembler classes; those, along with a new set of mock classes
defined in stackwalker_unittest_utils.h, make it possible for us to
actually do proper unit testing of a stack walker. These tests get us
full code coverage for stackwalker_x86.cc.
a=jimblandy, r=mmentovai
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@548 4c0a9323-5329-0410-9bdc-e9ce6186880e
This also adds two new test utility class groups, TestAssembler and
SynthMinidump. These are overkill for what I'm doing with them here
(and may simply be overkill, period), but they make it easy to write
unit tests for code that works on binary files or raw memory contents
in a cross-platform way. I'm planning to use them for the DWARF CFI
unwinding tests and the DWARF CFI parser tests.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@547 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 versions of the libstdc++, the GNU standard C++ library, have
stream extractors for unsigned integer values that permit a leading
'-' sign (6.0.13); others do not (6.0.9). Regardless of the behavior
of the extractors, Breakpad postfix expressions should support
negative literals.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@537 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
This is preparation for adding support for reading Linux C++ exception
handling data's encoded pointers. The change should have no user-visible
effect; it simply expands the comments for dwarf2reader::ByteReader, and
regroups the member functions.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@522 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 looks a little odd right now, since ParseStackInfo has only one
alternative to handle, but I think breaking this out should make the
subsequent addition of STACK CFI record support easier to review.
a=jimblandy, r=mmentovai
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@514 4c0a9323-5329-0410-9bdc-e9ce6186880e
Rename BasicSourceLineResolver::Module::StackInfoTypes to
WindowsFrameInfoTypes. This enum really describes the forms of
Windows-specific stack unwinding data (STACK WIN records), and its
name should reflect that, especially since we'll be adding support for
other kinds of stack walking information.
The 'stack' -> 'frame' shift matches the naming of the
WindowsFrameInfo type.
Similarly, rename BasicSourceLineResolver::Module::stack_info_ to
windows_frame_info_.
Do similar renamings in basic_source_line_resolver_unittest.cc.
a=jimblandy, r=mmentovai
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@513 4c0a9323-5329-0410-9bdc-e9ce6186880e
This patch moves the code for finding caller frames using STACK WIN
data and the code to do so using the traditional frame layout (%ebp
points at saved %ebp, pushed just after return address) into their own
functions. In addition to making things a little clearer, this is
preparation for adding support for STACK CFI records into the mix.
a=jimblandy, r=mmentovai
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@512 4c0a9323-5329-0410-9bdc-e9ce6186880e
This adds an EvaluateForValue member function to PostfixEvaluator, and
along with appropriate unit tests.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@511 4c0a9323-5329-0410-9bdc-e9ce6186880e
The Google C++ Style Guide requires all parameters passed by reference
to be labeled 'const', and says that pointers should be used for
output arguments. This patch brings google_breakpad::StackwalkerX86
into line.
a=jimblandy, r=mmentovai
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@510 4c0a9323-5329-0410-9bdc-e9ce6186880e
In order to be able to treat any MemoryRegion as const, the accessor
functions need to be declared this-const, which means annotations on
all the subclasses, etc. etc.
Since MinidumpMemoryRegion fills its memory_ member on demand, that
member needs to be marked 'mutable', but this is exactly the sort of
situation the 'mutable' keyword was intended for, so that seems all
right.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@509 4c0a9323-5329-0410-9bdc-e9ce6186880e
At the moment, StackwalkerX86::GetCallerFrame doesn't save the
WindowsFrameInfo that it finds for a frame unless it successfully
constructs the caller frame. This means that the windows_frame_info
field of the last frame on the stack is left unset, even when that
frame does have windows unwinding information.
This is not user-visible behavior, so it doesn't matter, but it is a
blemish on the interface, and unit tests (added in a later patch)
expect it.
This patch saves the information in the frame as soon as we find it.
a=jimblandy, r=mmentovai
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@508 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 patch moves the ReadInitialFunction from dwarf2reader.cc, where
it was a static function, to being a member function of
google_breakpad::ByteReader.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@504 4c0a9323-5329-0410-9bdc-e9ce6186880e
In r480, I botched the change to make the comparisons that decide
whether an address falls within a function's range safe from overflow.
The original code said:
address >= function_base && address < function_base + function_size
which is fine unless the function abuts the end of the address space,
in which case the addition overflows and you get a false negative.
My change subtracted function_size from both sides of the latter
comparison, which is meaning-preserving in true math, and gets you:
address >= function_base && address - function_size < function_base
This not only reads strangely, but also still overflows if
function_size is greater than address. That's rare, but I've added a
case to the unit tests that checks it.
My intent had been to replace the addition which could overflow with a
subtraction that was known not to overflow, namely:
address >= function_base && address - function_base < function_size
This is equivalent to the original in true math, and because of the
first comparison, we know the subtraction won't underflow in MemAddr
math.
The patch includes similar fixes to the public symbol lookup code, and
to FindWindowsFrameInfo, which was the only other function affected by
r480.
a=jimblandy, r=mmentovai
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@503 4c0a9323-5329-0410-9bdc-e9ce6186880e
Having NDEBUG be the default has wasted my time more often than I'm
proud to admit. There are no expensive asserts in the Linux symbol
dumper.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@502 4c0a9323-5329-0410-9bdc-e9ce6186880e
RangeMaps use the range's upper end as the key in the underlying map,
but RetrieveNearestRange was treating the key as the lower end.
a=jimblandy, r=mmentovai
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@501 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
dwarf2reader::CompilationUnit is a simple and direct parser for DWARF
data, but its handler interface is not convenient to use. In
particular, the same handler object receives data about all DIEs
processed. One can't use distinct classes to separate the information
needed to handle different kinds of data.
This patch defines a new adapter type, dwarf2reader::DIEHandler, which
implements the existing DWARF parser's handler interface, given a
handler written to a more comfortable, object-orient interface. The
comments in dwarf2diehandler.h provide more detail.
a=jimblandy, r=ccoutant
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@495 4c0a9323-5329-0410-9bdc-e9ce6186880e
Breakpad's DWARF line number info parser provides a code address,
file, and line number for each code/source pairing, but doesn't
provide the length of the machine code. This makes that change, as
discussed in the following thread:
http://groups.google.com/group/google-breakpad-dev/browse_thread/thread/ed8d2fde79319368p
This patch also makes the corresponding changes to the functioninfo.cc
module, used by the Mac dumper. This patch has no effect on the Mac
dumper's output.
a=jimblandy, r=ccoutant
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@494 4c0a9323-5329-0410-9bdc-e9ce6186880e
The DWARF specification specifices which names the sections containing
DWARF information should have. OSX uses slightly different names. This
patch changes the DWARF reader to look for the sections under both
sets of names.
a=jimblandy, r=ccoutant
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@493 4c0a9323-5329-0410-9bdc-e9ce6186880e
At the moment, the StackWalker GetCallerFrame member function expects
a vector of WindowsFrameInfo structures, even though WindowsFrameInfo
is only used or useful on one one implementation (StackWalkerX86).
This patch changes StackWalker::GetCallerFrame to no longer expect the
WindowsFrameInfo structures, and changes all implementations to match.
In particular, StackWalkerX86 is changed to find the WindowsFrameInfo
data itself, and store a pointer to whatever it got in the StackFrame
object itself (which is really a StackFrameX86).
To allow GetCallerFrame implementations to look up stack walking data,
StackWalker::resolver_ needs to be made protected, not private.
a=jimblandy, r=mmentovai
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@491 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
This adds a new variable, TEST_WRAPPER, to src/tools/linux/dump_syms.
Comments in the patch provide details.
This patch also moves the public variable section to sit after the
public phony targets.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@486 4c0a9323-5329-0410-9bdc-e9ce6186880e
Add a new member function to dwarf2reader::Dwarf2Handler,
ProcessAttributeReference, for reporting attribute values that are
references to other DIEs. This handler member function always receives
an absolute offset (that is, relative to the start of the .debug_info
section, not to the start of the compilation unit), regardless of the
form the attribute uses. (Some forms are CU-relative, some are
absolute.)
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@482 4c0a9323-5329-0410-9bdc-e9ce6186880e
src/processor/minidump.cc:1067: warning: format ‘%llx’ expects type ‘long long unsigned int’, but argument 3 has type ‘unsigned int’
src/processor/stackwalker_arm.cc:83: warning: unused variable ‘last_frame’
src/processor/minidump_stackwalk.cc:163: warning: ‘trust_name’ may be used uninitialized in this function
a=jimblandy, r=ted.mielczarek
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@481 4c0a9323-5329-0410-9bdc-e9ce6186880e
At the moment, FillSourceLineInfo returns Windows DIA-based stack
walking data. In addition to being ugly, this makes it difficult to
provide access to DWARF CFI-based stack walking data in a symmetrical
way.
This patch changes FillSourceLineInfo to do the single job its name
suggests, and adds a second member function to
SourceLineResolverInterface to retrieve Windows DIA stack walking
information. A sibling member function will provide access to DWARF
CFI stack walking data.
a=jimblandy, r=mmentovai
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@480 4c0a9323-5329-0410-9bdc-e9ce6186880e
Also, rename stack_frame_info.h to windows_frame_info.h.
If it seems odd to have functions like FillSourceLineInfo returning
Windows-specific data structures... well, it is! This patch just makes
it more obvious what's going on.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@471 4c0a9323-5329-0410-9bdc-e9ce6186880e
This patch avoids comparisons between signed and unsigned values, as
warned about by G++ 4.4.1.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@469 4c0a9323-5329-0410-9bdc-e9ce6186880e
