aboutsummaryrefslogtreecommitdiff
path: root/src/common/mac/dump_syms.cc
Commit message (Collapse)AuthorAgeFilesLines
* fix pointer style to match the style guideMike Frysinger2020-07-151-35/+35
| | | | | | | | | | We do this in a lot of places, but we're inconsistent. Normalize the code to the Google C++ style guide. Change-Id: Ic2aceab661ce8f6b993dda21b1cdf5d2198dcbbf Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2262932 Reviewed-by: Sterling Augustine <saugustine@google.com> Reviewed-by: Mark Mentovai <mark@chromium.org>
* Add support for dwarf5 line tables.Sterling Augustine2020-07-141-3/+8
| | | | | | Change-Id: I2c0cd0e7163502e52fbf0745b611befb2e219071 Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2276193 Reviewed-by: Sterling Augustine <saugustine@google.com>
* Use stdint.h numeric typesJoshua Peraza2020-04-091-8/+8
| | | | | | Change-Id: Ib815b0757539145c005d828080b92cbfa971a21b Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2141226 Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
* Mac dump_syms: accept __DWARF segment without __debug_info sectionMark Mentovai2019-08-071-12/+6
| | | | | | | | | | | | | | | | | | | | | | | | | A .dSYM may validly contain a __DWARF segment without any __debug_info section. This can occur for Chromium Framework in a component build of Chromium, because in that case, all of the code is in other libraries that Chromium Framework depends on. This was previously tested by an assertion, but the assertion did not trigger in NDEBUG (release) builds. In NDEBUG builds, this condition would lead to an out-of-bounds read, detected by AddressSanitizer. Instead of an assertion, the check is now always done at runtime. Instead of being fatal, it's now just a warning, because it's been established that __DWARF without __debug_info can occur. (In the Chromium case, it remains pointless to run dump_syms via the "chrome_dump_syms" target on a component build, as it'll only attempt to symbolize Chromium Framework, and not any of the libraries that Chromium Framework depends on that actually contain the code.) Bug: chromium:991206 Change-Id: I6c9c75f0be7901813e3eaae54aff38c1afe73ca9 Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1741610 Reviewed-by: Robert Sesek <rsesek@chromium.org>
* Add support for parsing the DW_AT_ranges attributesGabriele Svelto2018-08-131-1/+41
| | | | | | | | | | | | | | | | This enables the DWARF reader to properly parse DW_AT_ranges attributes in compilation units and functions. Code covered by a function is now represented by a vector of ranges instead of a single contiguous range and DW_AT_ranges entries are used to populate it. All the code and tests that assumed functions to be contiguous entities has been updated to reflect the change. DW_AT_ranges attributes found in compilation units are parsed but no data is generated for them as it is not currently needed. BUG=754 Change-Id: I310391b525aaba0dd329f1e3187486f2e0c6d442 Reviewed-on: https://chromium-review.googlesource.com/1124721 Reviewed-by: Ted Mielczarek <ted.mielczarek@gmail.com>
* Provide helper wrappers for basename(3) and dirname(3)Tobias Sargeant2017-10-181-3/+2
| | | | | | | | | | This hides the need to provide mutable C strings, and unifies existing basename calls and variations in a single location. Change-Id: Idfb449c47b1421f1a751efc3d7404f15f8b369ca Reviewed-on: https://chromium-review.googlesource.com/725731 Reviewed-by: Mark Mentovai <mark@chromium.org> Reviewed-by: Mike Frysinger <vapier@chromium.org>
* Corrected some old references to mm files, which were renamed to cc files a ↵Ivan Penkov2016-09-011-1/+1
| | | | | | | | | | | | while ago. Patch provided by Thomas Schweitzer. BUG= Change-Id: I1721db8cab7774b433ff6703a0ddc1eab6620c0b Reviewed-on: https://chromium-review.googlesource.com/379898 Reviewed-by: Mark Mentovai <mark@chromium.org>
* Add debug fission support.Yunlian Jiang2016-05-041-1/+2
| | | | | | | | | | | | | | | | | | | | | This added debug fission support. It tries to find the dwp file from the debug dir /usr/lib/debug/*/debug and read symbols from them. Most of this patch comes from https://critique.corp.google.com/#review/52048295 and some fixes after that. The elf_reader.cc comes from TOT google code. I just removed some google dependency. Current problems from this patch 1: Some type mismatch: from uint8_t * to char *. 2: Some hack to find the .dwp file. (replace .debug with .dwp) BUG=chromium:604440 R=dehao@google.com, ivanpe@chromium.org Review URL: https://codereview.chromium.org/1884283002 .
* Added an option (-i) to have dump_syms output header information only.David Yen2016-04-081-54/+72
| | | | | | | | | | | | | | | | | It is often helpful to check if a particular symbol file dumped by dump_syms actually matches a version of a binary file we have. The symbol output contains an ID which can be used to see if it matches the binary file. Unfortunately, this ID is internally calculated and not a standard hash of the binary file. Being able to output the header information only will allow users to determine whether their symbol file is up to date or not. R=jochen@chromium.org BUG=561447 Review URL: https://codereview.chromium.org/1864823002 . Patch from David Yen <dyen@chromium.org>.
* convert to uint8_t* for binary data to fix -Wnarrowing build errorsMike Frysinger2016-01-261-4/+5
| | | | | | | | | | | | | | | Newer gcc versions default to -Werror=narrowing when using newer C++ standards (which we do). This causes issues when we try to stuff a value like 0xea into a char -- the value is out of range for signed char bytes. That's when gcc throws an error: .../bytereader_unittest.cc: In member function 'virtual void Reader_DW_EH_PE_absptr4_Test::TestBody()': .../bytereader_unittest.cc:400:55: error: narrowing conversion of '234' from 'int' to 'char' inside { } [-Wnarrowing] BUG=chromium:579384 TEST=`make check` passes R=mark@chromium.org Review URL: https://codereview.chromium.org/1605153004 .
* Fix Mac Breakpad host tools to build in Linux cross-compileTed Mielczarek2015-09-161-0/+626
We're working on building our Firefox Mac builds as a Linux cross-compile (https://bugzilla.mozilla.org/show_bug.cgi?id=921040) and we need symbol dumping to work. This change ports the Mac dump_syms tool to build and work on Linux. I've tested it and it produces identical output to running the tool on Mac. The bulk of the work here was converting src/common/mac/dump_syms.mm and src/tools/mac/dump_syms/dump_syms_tool.mm from ObjC++ to C++ and removing their use of Foundation classes in favor of standard C/C++. This won't compile out-of-the-box on Linux, it requires some Mac system headers that are not included in this patch. I have those tentatively in a separate patch to land in Gecko (http://hg.mozilla.org/users/tmielczarek_mozilla.com/mc/rev/5fb8da23c83c), but I wasn't sure if you'd be interested in having them in the Breakpad tree. We could almost certainly pare down the set of headers included there, I didn't spend too much time trying to minimize them (we primarily just need the Mach-O structs and a few associated bits). I just realized that this patch is missing updating the XCode project files (ugh). I'll fix that up in a bit. R=mark@chromium.org BUG=https://bugzilla.mozilla.org/show_bug.cgi?id=543111 Review URL: https://codereview.chromium.org/1340543002 .
generated by cgit v1.2.1 (git 2.18.0) at 2025-02-01 23:46:43 +0000