| commit | 9ecccc5512f51982700c5ec8827de4ca7e9f0462 | [log] [tgz] |
|---|---|---|
| author | Sterling Augustine <saugustine@google.com> | Fri Oct 02 11:14:49 2020 -0700 |
| committer | Sterling Augustine <saugustine@google.com> | Thu Oct 08 21:59:15 2020 +0000 |
| tree | 50b0302ff33706508717ebab166fa6b4035b0eeb | |
| parent | 5c7535af7808b02de0c6670cf16086efe48ebd89 [diff] |
Implement dwarf5 range lists. This is a big change. dwarf5 range lists are quite a bit more complicated than dwarf 4 range lists, both in the contextual information required, and in their own representation and interpretation. The big design choice here is how to pass the CU information all the way down to the reader. I chose a structure, because otherwise the parameter list gets very long and error prone (and has to be passed down several levels). This structure could be made a parto of the CU context itself, or the range handler, so it wouldn't have to be separately assembled at range-list read time, but both of those solutions get even more invasive, and harder to follow. I've tried to figure out how to break this into smaller changes, but it affects nearly everything that has to do with a compilation unit's own addresses and when decisions must be made about how to read them. Dependency injection will do that to you. It does add tests for range list reading, which did not exist before. Change-Id: I923b9a2c3379a0f52609bc05310097de5cbb7227 Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2446635 Reviewed-by: Joshua Peraza <jperaza@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.