Breakpad Linux dumper: Tolerate STABS data from code linked with --gc-sections.

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

1 files changed, 6 insertions, 0 deletions

diff --git a/src/common/linux/dump_stabs.h b/src/common/linux/dump_stabs.h
index fb69e596..e6ea1d54 100644
--- a/src/common/linux/dump_stabs.h
+++ b/src/common/linux/dump_stabs.h
@@ -63,6 +63,7 @@ class DumpStabsHandler: public google_breakpad::StabsHandler {
   // store it all in MODULE.
   DumpStabsHandler(Module *module) :
       module_(module),
+      in_compilation_unit_(false),
       comp_unit_base_address_(0),
       current_function_(NULL),
       current_source_file_(NULL),
@@ -109,6 +110,11 @@ class DumpStabsHandler: public google_breakpad::StabsHandler {
   // finding the next object.
   vector<Module::Address> boundaries_;
 
+  // True if we are currently within a compilation unit: we have gotten a
+  // StartCompilationUnit call, but no matching EndCompilationUnit call
+  // yet. We use this for sanity checks.
+  bool in_compilation_unit_;
+
   // The base address of the current compilation unit.  We use this to
   // recognize functions we should omit from the symbol file.  (If you
   // know the details of why we omit these, please patch this