aboutsummaryrefslogtreecommitdiff
path: root/src/google_breakpad/processor/basic_source_line_resolver.h
Commit message (Collapse)AuthorAgeFilesLines
* Breakpad: Update copyright notice years on all files changed in 2010.jimblandy2010-02-091-1/+1
| | | | | | | | | | 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
* Issue 49013: Breakpad Processor: Use a separate API to retrieve Windows ↵jimblandy2010-01-111-1/+3
| | | | | | | | | | | | | | | | | | | | stack debugging info. 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
* Issue 49012: Breakpad Processor: Rename 'StackFrameInfo' structure to ↵jimblandy2009-12-231-1/+1
| | | | | | | | | | | | | | | 'WindowsFrameInfo'. 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
* Breakpad: Don't use the deprecated __gnu_cxx::hash_map container.jimblandy@gmail.com2009-09-031-24/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Modify symbol supplier interface to support an overload that takes a symbol ↵nealsid2009-02-191-0/+6
| | | | | | | | | | data buffer, to get around an extraneous read/write of symbol data R=doshimun git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@311 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Allow Breakpad processor library to build on Solaris with the native Sunmmentovai2007-09-261-0/+24
| | | | | | | toolchain (#142). Patch by Alfred Peng. r=me. git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@213 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Rename Airbag to Breakpad.mmentovai2007-02-141-0/+84
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@122 4c0a9323-5329-0410-9bdc-e9ce6186880e