| commit | 7c409af709da1be4fd35a0306b3f3511fc70f090 | [log] [tgz] |
|---|---|---|
| author | Mark Mentovai <mark@chromium.org> | Wed Sep 13 14:18:00 2017 -0400 |
| committer | Mark Mentovai <mark@chromium.org> | Wed Sep 13 19:50:52 2017 +0000 |
| tree | 4d4cb03f9de797822f38aab015cba2cd3db526a9 | |
| parent | a1dbcdcb43148c9eb31cbae74086adbb6ecb970e [diff] |
Parse DWARF 4 line tables correctly Breakpad’s DWARF line table reader only understood line tables at the level of DWARF 2. This wasn’t a problem because LLVM only produced line tables at this level, even when generating DWARF 4. But LLVM would like to output DWARF 4 line tables when generating DWARF 4, and Breakpad needs to understand this format. (Meanwhile, it seems that GCC has used DWARF 4 line tables with DWARF 4 output since 4.5.0, 2010-04-14.) DWARF 3 line tables are fully compatible with DWARF 2 (assuming that nothing needs “prologue end,” “epilogue begin,” or “isa”, and opcodes related to these fields are properly skipped). DWARF 4 changes the line number program header slightly to include a “maximum operations per instruction” field. This field must be recognized, but can safely be ignored (and assumed to be always 1) if VLIW architectures are not supported (they aren’t). DWARF 4 also introduces a “discriminator”, whose opcode can also be skipped if these values are not needed (they shouldn’t be). This recognizes the “maximum operations per instruction” field when processing DWARF 4 line tables, but asserts that its value is 1 and otherwise ignores it. This is not compatible with VLIW architectures that set this field to a value other than 1. Such architectures are irrelevant to Breakpad, and mainline GCC and the proposed LLVM patch always set this field to 1. There are other things that could be extracted from DWARF 3 and 4 line tables that aren’t currently extracted (although these are currently irrelevant to Breakpad too). Bug: google-breakpad:745 Change-Id: I5bf9c0b1aa654849c9cce64e60682447d10be8ba Reviewed-on: https://chromium-review.googlesource.com/663441 Reviewed-by: Mike Frysinger <vapier@chromium.org>
Breakpad is a set of client and server components which implement a crash-reporting system.
First, download depot_tools and ensure that they’re in your PATH.
Create a new directory for checking out the source code (it must be named breakpad).
mkdir breakpad && cd breakpad
Run the fetch tool from depot_tools to download all the source repos.
fetch breakpad
cd src
Build the source.
./configure && make
You can also cd to another directory and run configure from there to build outside the source tree.
This will build the processor tools (src/processor/minidump_stackwalk, src/processor/minidump_dump, etc), and when building on Linux it will also build the client libraries and some tools (src/tools/linux/dump_syms/dump_syms, src/tools/linux/md2core/minidump-2-core, etc).
Optionally, run tests.
make check
Optionally, install the built libraries
make install
If you need to reconfigure your build be sure to run make distclean first.
To update an existing checkout to a newer revision, you can git pull as usual, but then you should run gclient sync to ensure that the dependent repos are up-to-date.
Follow the steps above to get the source and build it.
Make changes. Build and test your changes. For core code like processor use methods above. For linux/mac/windows, there are test targets in each project file.
Commit your changes to your local repo and upload them to the server. http://dev.chromium.org/developers/contributing-code e.g. git commit ... && git cl upload ... You will be prompted for credential and a description.
At https://chromium-review.googlesource.com/ you'll find your issue listed; click on it, then “Add reviewer”, and enter in the code reviewer. Depending on your settings, you may not see an email, but the reviewer has been notified with google-breakpad-dev@googlegroups.com always CC’d.