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
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
