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
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
Fix typos.
For CompilationUnit::Start, I was confused by the '-' in the original
comment, taking it for a parenthetic clause marker, assuming an
implicit "of the next compilation unit" at the end of the sentence.
The comments should refer to the ".debug_info" section, not the
"debug_info" section. The latter is not the section name actually used
on any system (ELF or Mach-O), and the former is the name prescribed
by the DWARF spec.
Some of the comments for ProcessAttribute* member functions claim that
OFFSET is from the start of the compilation unit, but that's not so:
the code has always passed an offset relative to the start of the
.debug_info section.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@453 4c0a9323-5329-0410-9bdc-e9ce6186880e
src/common/dwarf/dwarf2reader.cc uses the old-fashioned <stdio.h>
facilities to report errors. Ideally, we would add a 'Warning' message
to the handler and make the client responsible for dealing with the
errors, but this at least allows us to compile.
Ubuntu 9.10 uses GCC 4.4.1; under older versions of GCC, this wasn't a
problem, probably because stdio.h was being brought in inadvertently
somewhere else.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@449 4c0a9323-5329-0410-9bdc-e9ce6186880e
It seems that a use of the <stdint.h> type uintptr_t has crept into
the DWARF parser. This defines a workaround for the GNU compilers
(tested on both Mac and Linux) which will raise an error if it doesn't
work.
My personal preference would be just to assume that the <stdint.h>
header is available and use the standard types everywhere, but 1) that
would be a large change, likely to make merges with the other branches
of the DWARF parser more difficult, and 2) it would make it quite
difficult to build under Microsoft Visual Studio, which doesn't have
the <stdint.h> header; Microsoft has said they have no plans to
provide it, as they would rather "focus their efforts" on C++ and
.NET.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@448 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
Move the DWARF parser, and the functioninfo.cc DWARF consumer, from
src/common/mac/dwarf to src/commmon/dwarf, so that it can be shared
between the Mac and Linux dumpers.
Fix up #include directives, multiple inclusion protection macros, and
Xcode build files.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@446 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
Use GNU Make features to make the dumper, unit tests, and maintenance
targets more independent, so I get fewer conflicts as I work on
different parts of the patch series.
In particular:
- Provide targets to run tests and produce test coverage reports.
- Gather C and C++ build rules in one place.
- Avoid variables that list object files, as pattern rules can compute
these values directly from the dependencies.
- Use VPATH to find sources in other directories.
a=jimb, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@441 4c0a9323-5329-0410-9bdc-e9ce6186880e
Modern GNU compilers warn about the #inclusion of <ext/hash_map>; that
container is deprecated, and code should use <tr1/unordered_map>
instead. However, to stay within the boundaries of C++ '98, it's
probably fine just to use plain old std::map.
Breakpad uses hash_map in three cases:
o The DWARF reader's SectionMap type maps object file section names to
data. This map is consulted once per section kind per DWARF
compilation unit; it is not performance-critical.
o The Mac dump_syms tool uses it to map machine architectures to
section maps in Universal binaries. It's hard to imagine there
ever being more than two entries in such a map.
o The processor's BasicSourceLineResolver uses a hash_map to map file
numbers to file names. This is the map that will probably have the
most entries, but it's only accessed once per frame, after we've
found the frame's line entry.
a=jimblandy
r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@393 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
std::vector::erase() invalidates the iterator, so we need
to advance the iterator by using the return value of erase().
R=nealsid
A=wtc
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@370 4c0a9323-5329-0410-9bdc-e9ce6186880e
STABS information introduces a compilation unit with an N_SO entry
whose address is the start address of the file and whose string is the
name of the compilation unit's main source file. However, STABS
entries can only hold one address, so STABS indicates the compilation
unit's ending address with an N_SO entry whose name is empty.
Currently, the dumper's data structures simply create SourceFileInfo
structures with empty names for these end-of-unit N_SO entries. We
want to remove STABS-specific characteristics from these structures so
that we can replace them with an input-format-independent structure.
This moves end-of-compilation-unit addresses out of the symbol table
structure, and into their own list of boundary addresses.
a=jimblandy
r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@369 4c0a9323-5329-0410-9bdc-e9ce6186880e
Use a list of pointers to SourceFileInfo structures, not a list of the
structures themselves. This is preparation for a subsequent patch
which makes the data structures less STABS-specific.
This patch introduces a memory leak. If an included file is
referenced only by line entries for functions that LoadFuncSymbols
elected to omit from the func_info list, then its SourceFileInfo
structure is leaked when we destroy the name_to_file map. This leak
is fixed in a subsequent patch by letting the map of files by name own
the file objects.
a=jimblandy
r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@368 4c0a9323-5329-0410-9bdc-e9ce6186880e
Replace the sorted lists of files and functions with an array of
boundary addresses. This replaces CompareAddress with the default
comparison, and SortByAddress and NextAddress with the stock STL sort
and upper_bound algorithms, losing ~50 lines of code.
a=jimblandy
r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@367 4c0a9323-5329-0410-9bdc-e9ce6186880e
In NextAddress, check both the file list and the function list for the
nearest boundary. Don't assume that, if we find any bounding entry in
the function list, that must be the nearest thing.
A=jimblandy
R=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@365 4c0a9323-5329-0410-9bdc-e9ce6186880e
The current arrangement would produce needless warnings if
WriteSymbolFile were ever used twice in the same program invocation.
Even if it weren't wrong, it's unnecessary, and local non-const static
variables require extra care when reading to be sure of their effect.
A=jimblandy
R=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@363 4c0a9323-5329-0410-9bdc-e9ce6186880e
With this patch, the time required to generate Breakpad symbols for
Firefox's libxul.so on a MacBook Pro 3,1 drops from 32s to 2s.
I verified that this patch had no effect on the output of dump_syms
when applied to firefox-bin and its libraries when built with -gstabs+.
A=jimblandy
R=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@362 4c0a9323-5329-0410-9bdc-e9ce6186880e
- Made localization for UI entirely string-based, with flexible layout based on the size of the strings inserted.
- Made the request for an email address optional.
- Fixed a bug that would prevent comments or email from being collected if the text field were still focused.
- Refactored askUserPermissionToSend.
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@335 4c0a9323-5329-0410-9bdc-e9ce6186880e
