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>
Breakpad skips the xstate area in x64 contexts but allowed this area
to be of unconstrained size. This hits problems if the size is greater
than Chrome's maximum allocation size, so we change to skipping a
maximum size. The maximum is chosen to allow the full set of states
today, plus some slack for the future:
Based on Intel x64 manual 13.5 XSAVE-MANAGED STATE
* => further bytes might be reserved
| Size | Region |
| 576 | Legacy + header |
| 384 | AVX State |
| 80 | MPX State |
| 1600 | AVX-512 State |
| 72*| PT State |
| 8 | pkru state |
| 8 | pasid state |
| 16 | CET state |
| 8 | HDC State |
| 96?| uintr state |
| 808*| lbr state |
| 8 | hwp state |
| 16 | amx state |
== 3680 so jump up a bit for the future to 2**12.
Bug:1425631
Change-Id: Ie08555651977cdbfa1c351c661118f13238213c4
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4379497
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
RISC-V register names are needed in order to load DWARF call frame
information.
Bug: fuchsia:124084
Change-Id: I2791b3a38ea35ddc2bb293f60f75dcc86338e354
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4376827
Reviewed-by: Mike Frysinger <vapier@chromium.org>
`dump_syms` fails to write symbol file without knowing how to convert
the ELF `e_machine` field to a string.
Use "riscv" as the value because ELF `e_machine` does not distinguish
between 32 bit and 64 bit RISC-V.
Test: run `dump_syms` on the libc++ that's shipped with the Clang
toolchain, or any other riscv binary: `./dump_syms -r -n libc++.so -o
Fuchsia <clang_path>/lib/riscv64-unknown-fuchsia/libc++.so.2.0`
Bug: fuchsia:124084
Change-Id: Ic04db96ec3d3d484350bdd0b90c9dfb70d7f7eb2
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4376828
Reviewed-by: Mike Frysinger <vapier@chromium.org>
`NXFindBestFatArch` is deprecated in macOS 13. We use this when an
architecture is passed in via the `-a` flag. Unfortunately, neither
of the potential replacements can help with this use case:
- `macho_for_each_slice` as suggested in a reply to FB11955188 just
enumerates slices, without the logic for inexact matches (for example,
x86_64h -> x86_64 or arm64e -> arm64).
- `macho_best_slice` as recommended by the deprecation notice only
supports finding a suitable slice to run on the local machine.
We could adapt the logic in `NXFindBestFatArch` but it gets quite
complex for some architectures. Instead, this change adapts the
`NXFindBestFatArch` polyfill used in `dump_syms_mac` for Linux, which
returns an exact match if possible, and the first slice that matches
the requested CPU type otherwise. I think this is probably Good
Enough for most cases; if not, we can try porting the x86_64 and ARM
logic and falling back to this for the rest.
Change-Id: I3b269dab7246eced768cecd994e915debd95721a
Bug: chromium:14206541420654
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4335477
Reviewed-by: Mark Mentovai <mark@chromium.org>
Previously, dump_syms always used the basename of the on-disk file as
the Breakpad module name and required that the on-disk filename of the dSYM and binary file match, or it would exit with an error.
Build automation often uses filenames unrelated to the Breakpad module
name, so this CL adds a new optional "-n MODULE" argument to Mac
dump_syms that allows passing in the Breakpad module name from outside.
In this case, the basename of the on-disk file(s) is ignored and
no longer required to match.
Change-Id: Ic38e8cf762c79bce61d289b397293eff6c0039ce
Bug: b/273531493
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4338857
Reviewed-by: Robert Sesek <rsesek@chromium.org>
The added flag will print only one line per frame for the requesting
thread (This is mostly the crashing thread).
Refactor the code for printing the frame so it can be reused.
Bug: 1374075
Change-Id: I8a1c8b1a09740fcaa23c3cc642468622ee64ea73
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4339771
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
It's deprecated in macOS 13/iOS 16, so this is an incremental step towards using newly introduced APIs for those OSes.
Since the description field is no longer available in the new
mach-o/util.h API, stop using it, especially since architecture name is
sufficiently informative.
Bug: chromium:1420654
Change-Id: If2cec4f1fc88d13a71f011822bff61f173486b68
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4322265
Reviewed-by: Mark Mentovai <mark@chromium.org>
Added
#ifdef HAVE_CONFIG_H
#include <config.h>
#endif
to the beginning of all source files that didn't have it.
This ensures that configuration options are respected in all source
files. In particular, it ensures that the defines needed to fix Large
File System issues are set before including system headers.
More generally, it ensures consistency between the source files, and
avoids the possibility of ODR violations between source files that were
including config.h and source files that were not.
Process:
Ran
find . \( -name third_party -prune \) -o \( -name '.git*' -prune \) -o \( \( -name '*.cc' -o -name '*.c' \) -exec sed -i '0,/^#include/ s/^#include/#ifdef HAVE_CONFIG_H\n#include <config.h> \/\/ Must come first\n#endif\n\n#include/' {} + \)
and then manually fixed up src/common/linux/guid_creator.cc,
src/tools/solaris/dump_syms/testdata/dump_syms_regtest.cc,
src/tools/windows/dump_syms/testdata/dump_syms_regtest.cc,
src/common/stabs_reader.h, and src/common/linux/breakpad_getcontext.h.
BUG=google-breakpad:877
Fixed: google-breakpad:877
TEST=./configure && make && make check
TEST=Did the find/sed in ChromeOS's copy, ensured emerge-hana google-breakpad
worked and had fewer LFS violations.
TEST=Did the find/sed in Chrome's copy, ensured compiling hana, windows, linux, and
eve still worked (since Chrome doesn't used config.h)
Change-Id: I16cededbba0ea0c28e919b13243e35300999e799
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4289676
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Changes a recent introduction of sprintf to snprintf since sprintf is
deprecated in Chromium.
Bug: crashpad:329
Change-Id: Icd346da4c86bd8e867266dfebaf617991dd90113
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4261633
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Updates minidump_dump to print out any Crashpad annotation objects that
are in a minidump. If an annotation contains a string value, it will be
printed out as such, otherwise it will be printed out as hex bytes.
Bug: crashpad:329
Change-Id: Ieecd6381c623f9011b16357742f7145a118dbc3c
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4261631
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
If symupload client failed to connect the backend, we need this error
message to be exposed. This could help the failure we are facing in
official staging builders.
BUG=chromium:1401761
TEST=NA
Change-Id: Ic720aff9cb523c38553d6c02bf72aa5b95e862a7
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4240299
Reviewed-by: Nelson Billing <nbilling@google.com>
This change removes ScopedTmpFile from DisassemblerObjdump, and
replaces it with the use of the implementation in linux/common.
It also switches to using ScopedPipe to read the output from objdump,
and directly execing objdump instead of using system.
Change-Id: I6d425190fb4a20d6b265c72aa7315026687cb86a
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/3971919
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
This replaces the existing AutoTestFile implementation with a simpler
implementation that uses O_TMPFILE to avoid having the temporary files
linked in the filesystem.
Refactor the existing tests to use the new ScopedTmpFile instead of
duplicating the same ScopedTestFile wrapper into each test.
Change-Id: Iee9416e52269eff271f748ec9d822aee6e28f59a
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/3971917
Reviewed-by: Lei Zhang <thestig@chromium.org>
This checks in an edited version of a script that has been used by the
Chrome Mac team for this purpose. It expects to reside in the same
place as `dump_syms`, `dsc_extractor`[0], `symupload` and `upload_system_symbols` binaries.
When called, it will:
- Locate and extract any dyld_shared_caches found on the system
- Dump the above
- Dump any remaining uncached system libraries
- Write the results to a directory passed as an argument
- Provide (but not call) an `upload_system_symbols` invocation
to upload the results
[0] Not yet checked in
Bug: 1400770
Change-Id: I30610c23d0c979e34dd3830eeedb5ceeae8ce66b
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4111109
Reviewed-by: Mark Mentovai <mark@chromium.org>
LibcurlWrapper is missing a curl_global_cleanup causing a memory
leak. The curl_global_init is called automatically when calling
curl_easy_init without first doing curl_global_init.
BUG=chromium:1405410
TEST=units with asan
Change-Id: I4982fd5265b0df91076ed428f1134a681a7f28c6
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4189295
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
At the moment, the Minidump class only supports reading simple and
list annotations from Crashpad minidumps. This change adds support
for reading annotation objects stored in Crashpad modules
(MDRawModuleCrashpadInfo) and exposes them via a new getter in
MinidumpCrashpadInfo.
Change-Id: I033fc4a4fdff5901babc2472e0150f79af56b830
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4195756
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Remove the "noext" argument to AX_CXX_COMPILE_STDCXX(), so the configure
script can figure out what works, instead of only allowing strict
conformance mode.
See discussion on https://crrev.com/c/3954471, which lead to this CL.
Change-Id: I7688db2e267485003ae8f776fa3ca0dd63205b47
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4072453
Reviewed-by: Mark Mentovai <mark@chromium.org>
On macOS 13 x86_64 machines, NXFindBestFatArch does not correctly find
arm64e slices. This is filed as FB11955188.
I was hoping manually masking the subtype with CPU_SUBTYPE_MASK would
be sufficient to work around but no luck. So let's just fall through
to doing an exact* match if NXFindBestFatArch fails.
* "Exact" meaning with CPU_SUBTYPE_MASK now masked off. But
libmacho/arch.c calls that exact too, so I'm just going to go with it.
Bug: 1400770
Change-Id: Id497946d3c719285c5d7508e589e4a466da1ceca
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4178621
Reviewed-by: Mark Mentovai <mark@chromium.org>
Fix more memory leaks, specifically for Module::Extern and
Module::StackFrameEntry that were outside the Module's AddressRange.
To fix this, and to prevent issues like the one fixed by
79326ebe94
in the future, switched to proper use of std::unique_ptr for Module's
Extern and StackFrameEntry functions. These should enforce ownership
correctly and make the ownership flow much more visible and clear.
Change-Id: I7c943dff3501836a5e303febedc1b312e6f0a1fe
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4129821
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Emit STACK CFI records even in the presence of clang's "-gz" linker
option. Needed for ChromeOS ARM boards' chrome binary.
BUG=b:263148951,google-breakpad:874
Fixed: google-breakpad:874
Change-Id: I2fe697a56d3421609128d4e291ab1adc73314864
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4117692
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
This was previously setting the right upload servers too late to
use them when uploading previously dumped symbols (the
`--upload-from` use case)
Bug: 1400770
Change-Id: If5bb749707b9f0a181585619f30ec9cb011db5ed
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4111102
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Adds a new option, `-api-key`. If passed, `symupload` is invoked with
the `sym-upload-v2` protocol, the key is passed through, and the V2 API
upload servers are used.
Bug: 1400770
Change-Id: I81255dccc54038a57900058a050603b89e37d716
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4103749
Reviewed-by: Robert Sesek <rsesek@chromium.org>
- Fix a test build failure introduced by cc7abac08b.
- Use strcmp from <string> instead of std::strcmp from <cstring>.
Bug: google-breakpad:867
Change-Id: I8dcbc7d5ac8ea799b4d5287ddbbf5d6626992123
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4095054
Reviewed-by: Mike Frysinger <vapier@chromium.org>
