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
