Crashpad processor

[GoogleCodeExporter]

Crashpad should have its own processor. Here are some ideas:

 - Consume raw DWARF and native image files, no more dump_syms.
    - Enables more than just function, file name, and line number. Function parameters and variables can also be decoded.
    - The processor may still need to support dump_syms for compatibility.
    - DWARF data can be quite large, and it may be impractical to do this for many Crashpad users. -gline-tables-only is an option to reduce DWARF, but debugging information is lost and function parameters and variables cannot be extracted. A tool can be provided to minimize DWARF by subsetting the available data, if no such tool already exists.
    - For Windows, it will need to support something dump_syms-like, since it will not likely be able to read .pdb files directly on other platforms.
 - Built on the snapshot library, consumes live/crashed process images in addition to minidump files. In the future, will support native core files (bug 28) and more.
 - Stackwalking and other support to be provided by LLVM?

This is a lot of work. I expect other bugs for specific tasks to be filed, and 
for this bug to be blocked on those.

Original issue reported on code.google.com by mark@chromium.org on 28 Mar 2015 at 3:16

[GoogleCodeExporter]

Until this rather large project is implemented, I think it might make sense to 
port dump_syms over from Breakpad to Crashpad. One of the strengths of Crashpad 
(IMHO) is that compiling it is so easy now that is done from the command line. 
Granted I have no idea how much code and effort this would require. :-)

Original comment by wsto...@gmail.com on 1 Apr 2015 at 8:53

[GoogleCodeExporter]

No code will be coming over as-is from Breakpad. It doesn’t meet the 
standards for design, documentation, quality, and testability.

We made an exception for client/simple_string_dictionary and brought it over 
almost unchanged because it actually did meet the standards.

If the problem you’re having is just that dump_syms is difficult to build, 
you could take a look at Chromium’s .gyp file for it 
(https://chromium.googlesource.com/chromium/src/+/master/breakpad/breakpad.gyp).
 You can probably swipe the target starting at line 182 out of that file and 
adapt it for your needs. You’ll also notice the comment on line 239 that kind 
of makes part of my point.

Otherwise, you can build dump_syms with Breakpad’s .xcodeproj for it:

$ cd …/breakpad/src/tools/mac/dump_syms
$ xcodebuild -target dump_syms -configuration Release \
    GCC_VERSION=com.apple.compilers.llvm.clang.1_0 \
    GCC_OPTIMIZATION_LEVEL=0 \
    SDKROOT=macosx10.9 \
    MACOSX_DEPLOYMENT_TARGET=10.6 \
    ARCHS=x86_64
$ file build/Release/dump_syms
build/Release/dump_syms: Mach-O 64-bit executable x86_64

Original comment by mark@chromium.org on 1 Apr 2015 at 9:11

[GoogleCodeExporter]

What's the motivation here? I get the desire to rewrite the client bits due to 
changing platform expectations, but rewriting the processor seems like busywork.

Also re: PDB files, I've got a mostly-compatible Windows dump_syms replacement 
under a BSD license that works on POSIX:
https://github.com/luser/dump_syms

If you wanted to consume PDB files directly in the processor you could start 
with that code.

Original comment by ted.mielczarek on 8 May 2015 at 2:57

[GoogleCodeExporter]

The Breakpad processor has held up better than most of the rest of the Breakpad 
components, but that doesn’t mean it’s in great shape, and I don’t think 
that it would be easy to achieve some of the things we want to do in that 
codebase. The lack of strong tests really works against it, because even for 
the features that would be feasible to work into the Breakpad processor, 
there’s not a very strong guarantee that sweeping changes wouldn’t break 
anything.

Some of the things we’d like to do involve data sources other than minidump 
files, including native core files and live remote processes. Breakpad is tied 
heavily to the minidump format. We’d like to be able to walk stacks using 
native debugging data without having to run dump_syms where possible. Although 
Breakpad allows the dump_syms format to be easily replaced by something else, 
that “something else” needs to carry dump_syms-like data, such as STACK 
lines that can be fed to the postfix evaluator. I like how Jim was able to work 
DWARF into that scheme, but not all of DWARF is supported (DW_CFA_expression is 
missing, for example) and the requirement to work everything into STACK terms 
really does turn out to be limiting. We’d also like to take advantage of some 
of the better debugging tools that just didn’t exist when Breakpad first came 
into existence: I don’t think we should need to own the stackwalker 
implementations, for example, and I do think that we should be able to do 
things like recover parameters and variables from memory (this has always been 
the most-requested item).

None of this is busywork (and I think that’s a borderline offensive assertion 
for you to make). The Breakpad processor’s design and assumptions about 
minidump and dump_syms formats would really hold back progress. Breakpad’s 
processor is tied up with the minidump format, which frustrates attempts to 
move to interesting remote debugging-type models. Breakpad’s stackwalker is 
tied up with the dump_syms format and extracting any more information from 
minidumps than it does now would require a bunch of dump_syms work too, and 
dump_syms has already proven itself as a flakier part of the chain.

Original comment by mark@chromium.org on 8 May 2015 at 8:58