The version of Makefile.in that landed in https://crrev.com/c/4722191
had a Makefile.in that was generated from a previous version of
Makefile.am where the libzstd dependency wasn't optional. That's causing
some problems (see: https://crrev.com/c/5193965) and is a simple
mistake.
I generated this CL by simply running `automake`, so it simply makes the
checked in generated Makefile.in based on the checked in source
Makefile.am
Change-Id: Iabb4a99bfac3f5ef6067a140bd373c9fb894878a
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/5200626
Reviewed-by: Mike Frysinger <vapier@chromium.org>
This change introduces two new flags: `--ipsw` and `--installer` which are mutually exclusive with `--system-root` and each other. Each takes a file path as an argument, which is expected to be an IPSW for `--ipsw` and an Apple installer for `--installer`.
Calling `upload_system_symbols` with these arguments will cause it to find any dyld shared caches present inside the given IPSW or installer, extract them via `dsc_extractor` in `--breakpad-tools`, then behave as if it had been called with the resulting libraries as `--system-root`.
Bug: chromium:1400770
Change-Id: I7f98e0c6ab069a2e960f12773d800d8a5a37221f
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/5089008
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Minidumps can contain extended contexts with xstate data for amd64 and
x86.
Support for amd64 contexts was added in
fe35cd43f2.
With this change, breakpad can now read x86 minidumps that contain
extended xstate data. Similar to the previously mentioned commit, this
change does not yet add processing for this extra data, but will allow
the minidumps to be read.
Change-Id: Ie96e91168def774092e05908535a70fc5e2427e9
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/5154022
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Otherwise, even with core.autocrlf=false, Windows will checkout these minidump output files with CRLF line-ending. It is necessary for these
files to be checked out using LF line-ending for the unit tests to pass.
Change-Id: I7cacf4b5fa56e007c8aa81202e0cef7ad42ae93a
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/5160534
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
Windows doesn't have posix regex support. This will disable these tests so long as Google's ABSL library is not also found.
Change-Id: Ie6f96d5ea74b80b6128c2f1ec3ed54fcfaa17f47
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/5160533
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
In RangeMap::StoreRangeInternal, when size <= 0 and !high_ok then the
high variable is passed to HexString uninitialized.
Change-Id: I7e597cadaf248b607c646534a5d800c17ccdeda9
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/5155712
Reviewed-by: Robert Sesek <rsesek@chromium.org>
When building a stack trace using StackwalkerAddressList, if there are
inlined frames then the stack trace will skip over the following
frames, leading to missing frames in the symbolized stacktraces.
Bug: 314930064
Change-Id: I5c7a1b2e7c2f728e27b2082e77ebe953808f38bc
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/5087692
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Inline frames are always of the base-class type (StackFrame). Treating them as derived-class and accessing members is causing buffer overflows.
Change-Id: Ib41b74256e6162e7d2b14ca3905dfaf5591b9c86
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4847317
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Functions such as FindElfSection and FindElfSegments that inspect
the ELF header expect a pointer to the first byte of the file.
IsValidElf() checks for the ELF magic number at offset 0.
Thus, we must map ELF object files from offset 0.
Change-Id: Icebfb46229a04019f57a7ec07844257b98ceb278
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4674337
Reviewed-by: Mike Frysinger <vapier@chromium.org>
The _tmp buffer used in STRNCATF is too small for several callers,
which might lead to truncated output in some situations.
For example, GCC 11 warns:
src/third_party/libdisasm/x86_format.c:899:40: warning: ‘%s’ directive output may be truncated writing up to 63 bytes into a region of size 32 [-Wformat-truncation=]
899 | STRNCATF( buf, "%s:", str, len );
| ^~~~~ ~~~
src/third_party/libdisasm/x86_format.c:34:38: note: in definition of macro ‘STRNCATF’
34 | snprintf( _tmp, sizeof _tmp, fmt, data ); \
| ^~~
src/third_party/libdisasm/x86_format.c:899:41: note: format string is defined here
899 | STRNCATF( buf, "%s:", str, len );
| ^~
In file included from /usr/include/stdio.h:894,
from src/third_party/libdisasm/x86_format.c:1:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:71:10: note: ‘__builtin___snprintf_chk’ output between 2 and 65 bytes into a destination of size 32
71 | return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
72 | __glibc_objsize (__s), __fmt,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
73 | __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~
Change-Id: Ia876e288bf9629f2c72db3faf2287c7940924ea0
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4668735
Reviewed-by: Mike Frysinger <vapier@chromium.org>
The debug info in the dwp file needs to refer to the .debug_line and
.debug_line_str sections in the main binary.
This fixes dump_syms not generating LINE records for dwp in split dwarf.
Bug: chromium:1448979
Change-Id: I71923f12cea72caae081c1406e2cbca55e95859e
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4576346
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
The hex formatting in MinidumpCrashpadInfo::Print() was missing
the leading 0, so byte values < 128 were not possible to decode.
Change-Id: Ib355bcdaf86e91d644045df645fb4fa75332aa4b
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4571100
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
- RISCV32 will only include support for 32 bit floating point registers
- RISCV64 will only include support for 64 bit floating point registers
- RISCV 32/64 context will include a "version" field to account for
future extensions
Fixed: 1447862
Tested: `make check` on x86 host
Tested: `minidump_stackwalk` for RISCV64 minidump on x86 host
Change-Id: I605d5b2c35e627a5dc986aaf818a9c9898f6ae0b
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4553281
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
It fixes following two problems:
1. When we have skeleton compilation unit (DW_TAG_skeleton_unit) in a
binary file refers to the complete unit in a split dwarf file
(.dwo/.dwp file), we should use the split dwarf file's path in warning
reporting. Right now, it uses the original file (binary file) path in
warning report, which is incorrect.
For example, if we have chrome.debug which is the binary with skeleton
debug info and chrome.dwp which is the complete debug info and the debug
info in chrome.dwp has some incorrect reference, it will warn on
chrome.debug rather than chrome.dwp
2. When split dwarf is enabled, the global inline_origin_map will likely
encounter key collision because the offsets as keys are now relative to
each CU's offset which is relative to .debug_info section. Also
offsets from different files might collide.
This change makes a inline_origin_map for each debug file and use
offsets only relative to .debug_info section as keys.
Bug: b/280290608
Change-Id: If70e2e1bfcbeeeef2d425c918796d351a0e9ab3b
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4544694
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
macOS caps filenames at 255 characters. When upload_system_symbols runs
`dump_syms`, the resulting filename is based on a mangled version of
the file's full path. In some circumstances (for example, the dumped
file itself lives in a temp directory), this name can exceed the max.
This change replaces the current mangling by mapping each path component but the last to its first initial, greatly shortening
the resulting filename.
Bug: 1400770
Change-Id: I68203a98eda2912893c5d8f7c676faee17e39e91
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4519231
Reviewed-by: Robert Sesek <rsesek@chromium.org>
- Replace DISALLOW_COPY_AND_ASSIGN with =delete.
- Replace some NULLs with nullptrs;
- Use the override keyword when appropriate.
- Use =default when appropriate.
Change-Id: I99e1d7f349dd4c32aa5d05e2ebdce7a86e47f551
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4527718
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
This adds a new flag `enable_objdump_for_exploitability_` to the
MinidumpProcessor, which allows enabling objdump separately for crash
address fixups and for exploitability analysis, as the performance cost
of the exploitability analysis is significantly higher.
Change-Id: I667ffdce7cc0a970793f91413c3d2e3af93f4247
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4507067
Reviewed-by: Ivan Penkov <ivanpe@google.com>
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
Change 4505156 changed the RISCV register names, this change adjusts
the unittest to match the new names.
Bug: 1432426
Change-Id: I0887d8fc11eec63ab6953ea1a136873591e49286
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4507066
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
dump_syms was using x0...x31 notation, while the rest of Breakpad was
using the ABI names. This mismatch was causing stackwalking to not fully
succeed.
Fixed: 1432426
Change-Id: I0713e76e65ff6dad492b51bc3607e94e25dc2c3a
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4505156
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
MDRawCrashpadAnnotationList::objects is a flexible array of
MDRawCrashpadAnnotation and not MDLocationDescriptor. Breakpad does not
currently use the MDRawCrashpadAnnotationList type, but its definition
should be updated to reflect the correct type to avoid confusion.
Change-Id: I58b5b0e4f7f95bc003b103e2750e3759c3e31292
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4503630
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
MDRawModuleCrashpadInfoList::modules is a flexible array of
MDRawModuleCrashpadInfoLink and not MDLocationDescriptor. Breakpad does
not currently use the MDRawModuleCrashpadInfoList type, but its
definition should be updated to reflect the correct type to avoid
confusion.
Change-Id: If97f490db8d41529b59a225a275a37116746c2b7
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4504150
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Use the exception record's context for the crashed thread instead of
the thread's own context. For the crashed thread the thread's own
context is the state inside the exception handler. Using it would not
result in the expected stack trace from the time of the crash.
This change aligns the behavior of minidump-2-core with the behavior of
minidump_stackwalk.
Bug: google-breakpad:885
Change-Id: I5cd3e9d39807308491b64fcd335f5f85b1dcd084
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4473128
Reviewed-by: Joshua Peraza <jperaza@google.com>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Use MD_CONTEXT_AMD64_DEBUG_REGISTERS instead of
MD_CONTEXT_AMD64_DEBUG_REGISTERS in the definition of
MD_CONTEXT_AMD64_ALL. This previously happened to work because the two
flags happened to have the same values and every includer of
minidump_cpu_amd64.h also happened to previously include
minidump_cpu_x86.h.
Change-Id: If8b422d3623936f4a0b57a4cf6dac4f348daa024
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4480251
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
The NXArch* family is deprecated in macOS 13. This change:
- Uses the replacements where available
- Silences deprecation warnings otherwise
- Removes the Linux cross-compile shims in favor of having completely
separate implementations for Mac and non-Mac. The logic of the Linux
versions uses the same prepopulated data as before, but they no longer
use NXArchInfo.
clang diagnostic disables are necessary due to https://crbug.com/1406057
Bug: chromium:1420654, google-breakpad:880, b/257505171
Change-Id: Iad777915a5a058551cfb3a7d3cf681cce180dfea
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4437109
Reviewed-by: Mark Mentovai <mark@chromium.org>
These are reimported from Apple's Github source drops, see exact
provenance in README. Most were imported as is, some were edited
to match previous versions, and as noted below
- Added arm headers where needed
- Removed (now) unused `/mach/i386/vm_param.h`
- Removed availability annotations
- Removed `__kernel_ptr_semantics`
- Added `defined(__aarch64__)` to all arm64 define guards
Bug: chromium:1420654, google-breakpad:880, b/257505171
Change-Id: I17bd03fa871a8f1dc4285daafa3d7b26c2186e2b
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4482294
Reviewed-by: Mark Mentovai <mark@chromium.org>
This is a speculative fix for a memory bug where our symbol files are
looking like they've grown enough that serializing them will outgrow
UINT_MAX. Before this change a size_t is implicitly cast to a size_t in
unsigned int, allocate a buffer of that size and then continue to write
module data out of bounds.
I have not been able to reproduce the OOB write locally as the original
uploaded symbol data is gone, but I have been able to reproduce builds
where, if we enable inline frames and CFI dumping, the size grows to
3.6GB when serializing it, which is close enough to 4.2GB that the
wrapping theory seems reasonable on another board or build.
No effort is made here to prevent wrapping behavior on 32-bit systems.
Bug: b/237242489, chromium:1410232
Change-Id: I3d7ec03c51c298f10df3d5b1e5306433875c7919
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4477821
Reviewed-by: Leonard Grey <lgrey@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Previously, the logic to mark a symbol as "multiple" would always fire
for C++ symbols for Apple `.dSYM`s built with `-gmlt`.
This was because for a C++ symbol like `void foo::bar::Baz()`, the
DWARF data would contain the truncated function name `Baz`, but the
STABS would contain the fully-qualified name `void foo::bar::Baz()`.
This CL relaxes the name matching to not mark as multiple:
1) Symbols which were missing names entirely in the DWARF (e.g, "<name omitted">)`
2) Symbols whose fully-qualified name includes the truncated name as a substring
Bug: https://bugs.chromium.org/p/google-breakpad/issues/detail?id=883
Change-Id: I26ded7ca84d964aa4a73da19e4bdd7e686e2c998
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4470047
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
When built with -gmlt, .dSYMs are (by design) missing the
`DW_AT_linkage_name` which Breakpad uses to fill out the
(name-mangled) function names.
Thankfully, the .dSYM contains both the old-school LC_SYMTAB command
containing the STABS-format symbols (which include the fully-qualified
C++ symbol names we want, but no actual compilation unit data), as
well as the LC_SEGMENT_64 containing the __DWARF segment with the
minimal -gmlt debug information (which excludes the name-mangled C++
symbols).
Unfortunately, since the .dSYM's STABS does not define compilation
units, the usual path in `StabsReader` ignores all the fully-qualified
C++ symbol names for the functions:
bd9d94c708/src/common/stabs_reader.cc (100)
Fortunately, when built for macOS platforms (`HAVE_MACH_O_NLIST_H`),
`StabsReader` supports storing all the STABS-format symbols as
`Extern`s, regardless of whether or not they're in a compilation unit:
bd9d94c708/src/common/stabs_reader.cc (119)
Currently, when there's both a `Function` and an `Extern` with the same address, `Module` discards the `Extern`:
bd9d94c708/src/common/module.cc (161)
This CL adds a new `-x` option to the Mac `dump_syms` which prefers
the Extern function name if there's a mismatch.
Bug: https://bugs.chromium.org/p/google-breakpad/issues/detail?id=883
Change-Id: I0d32adc64fbf567600b0a5ca63c71c422b7f0f8c
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4453650
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Printing the register values as part of the stack trace relies on the
CPU architecture being "riscv" or "riscv64" rather than the numeric
identifiers (0x8005 and 0x8006, respectively).
Fixed: 1432306
Test: Run `minidump_stackwalk` on a RISC-V minidump
Change-Id: I0009da687438d51047e2ee39ffa1c50d78798caa
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4416399
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
