- Checking symbol status would fail for files whose names contained spaces, because the file name was being put in the URL unescaped.
- Now the filename is escaped before being put in URL when checking symbol status.
Change-Id: I3b989d877e0fd9aef57ec13bdbbb6c3dacb6a9e2
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2339782
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
These fields are only used when NDEBUG is not defined. We get build
failures with the current code like:
src/common/dwarf/dwarf2reader.h:181:12: error: private field 'string_buffer_length_' is not used [-Werror,-Wunused-private-field]
uint64_t string_buffer_length_;
Change-Id: I01d6e29d31d50e29ed3736e7197e70455724ae48
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2299022
Reviewed-by: Sterling Augustine <saugustine@google.com>
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>
For the upcoming Dwarf5 LineInfo changes, we will need to get
several additional sections by name, but without a the Compilation
Unit. This change prepares for that.
Change-Id: I566855abb339a856110a2f7d243d3848fe2b3c18
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2268861
Reviewed-by: Mark Mentovai <mark@chromium.org>
Given the almost nonexistent direct dwarfreader tests, I think
the best way to test these dwarf5 additions will be to add a full
dwarf5 compilation unit similar to the ones used incidentally in
the other tests. But I can't do that until enough dwarf5 is
correctly implemented.
Change-Id: I3418bda7212ae85c4b67232a2ab8fea9b9ca5d42
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2258838
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Adding the new forms by type and processing should avoid
the problems with 0c0e24f709,
where new forms weren't handled in switch statements, breaking
the build.
Testing this should follow the testing for DW_FORM_GNU_str_index,
very closely, but there doesn't appear to be any tests for that,
or even DW_FORM_strp.
Change-Id: I609d56b1dc879971bfef1070f063f8457fec6017
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2233839
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This should address the issue where some Chrome builds were failing to
upload symbols due to a bad command-line flag, but there was no
indication of a problem, and no build failure, because symupload was
exiting with a success code.
BUG=1091387
R=nbilling@google.com, wuwang@google.com
Change-Id: I0d7f1a6d689ca5fd37be3abad4c5ebc97f108e50
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2231574
Reviewed-by: Nelson Billing <nbilling@google.com>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Bogus demangler warnings should be suppressed on both Mac and Linux
platforms, so there is no reason to keep this filter behind __APPLE__ gate.
Bug: chromium:1062556
Change-Id: Idf28db0b527c3cd6dd91510fcf7d9040aaa64694
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2210684
Reviewed-by: Mark Mentovai <mark@chromium.org>
On Mac a C++ symbol has 1-4 underscore characters followed by a 'Z'.
Symbols that do not have this format (such as plain C symbols)
causes a lot of warnings to be printed.
Bug: chromium:1062556
Change-Id: I55977f756c7e20cc5e7b1cb8e38316d7bf1f748c
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2179482
Reviewed-by: Mark Mentovai <mark@chromium.org>
These are left over from when this file was written in C.
In C++, true and false are keywords, so this is no longer necessary.
In fact, redefining a keyword is not actually permitted in ISO C++
(https://eel.is/c++draft/macro.names#2), and is rejected by MSVC.
Change-Id: I2f4a6eae7f8dd4d91b8ee6588c7ae5e8f20bd0d0
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2105831
Reviewed-by: Mike Frysinger <vapier@chromium.org>
__WORDSIZE is an internal libc definition. Instead, we can use
ULONG_MAX from limits.h, whose value corresponds to the machine's
native word size.
This allows us to remove the fallback definition of __WORDSIZE in
the Android compatibility headers.
Bug: google-breakpad:631
Change-Id: I7b9e6f3b2121f78ccad9e32bf26acac518aefd8f
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2107100
Reviewed-by: Mike Frysinger <vapier@chromium.org>
getcontext is also not available on musl libc, so generalize
breakpad_getcontext so it can be used as a fallback for non-Android
platforms as well.
On x86_64 and i386, ucontext_t uses an Android-specific offset for
storage of FP registers, since its sigset_t differs in size. So,
make the definition of MCONTEXT_FPREGS_MEM and UCONTEXT_FPREGS_MEM_OFFSET
conditional on whether we are building for Android.
On glibc and musl, signal.h and asm/sigcontext.h can't be included
together, so in breakpad_context_unittest.cc, only compare the libc
and kernel _fpstate when on Android.
Bug: google-breakpad:631
Change-Id: If81d73c4101bae946e9a3655b8d1c40a34ab6c38
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2102135
Reviewed-by: Mike Frysinger <vapier@chromium.org>
The crash address from the microdump was never checked against
anything. Instead, the test was checking the value of a constant.
On 32-bit systems, an intptr_t cannot represent kCrashAddress
(0xDEADDEAD), causing a failure when the crash address is parsed
from the microdump. Instead, use uintptr_t, which matches the type
of kCrashAddress.
Change-Id: Ib5612743803609f7801dcfb98deaa8779e362025
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2100816
Reviewed-by: Mike Frysinger <vapier@chromium.org>
The _libc_fpstate struct tag is an implementation detail of glibc,
and musl uses a different struct tag, _fpstate.
Unfortunately, the public type fpregset_t is a pointer type, so is
not suitable for allocating storage, or referring to constant
storage. Instead, we can use std::remove_pointer<fpregset_t>::type
to refer to the pointed-to type, regardless of the struct tag.
Bug: google-breakpad:631
Change-Id: Iaf47f15b2d834dd8de839431f65a481e9b0c7f9e
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2096171
Reviewed-by: Mike Frysinger <vapier@chromium.org>
__WORDSIZE is an internal libc definition. Instead, we can use
ULONG_MAX from limits.h, whose value corresponds to the machine's
native word size.
Bug: google-breakpad:631
Change-Id: If69caf578286d678585d1510c01562b969b5061f
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2097352
Reviewed-by: Mike Frysinger <vapier@chromium.org>
sys/poll.h and sys/signal.h just redirect to the standardized
location for these headers, poll.h and signal.h.
On musl libc, including the incorrect header path results in a
warning, and since breakpad is built with -Werror, this is an error.
In exception_handler.cc, signal.h is already included earlier, so
we can drop the sys/signal.h include.
Bug: google-breakpad:631
Change-Id: If36d326453e3267d38a5b92ed1301f828e46befe
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2097344
Reviewed-by: Mike Frysinger <vapier@chromium.org>
This reverts commit 0c0e24f709.
Reason for revert: This is causing breakage on CrOS due to unhandled
enums and dwarf5 support is in limbo, so pull this back out for now.
Bug: google-breakpad:812
Change-Id: I22dd5d87efb8bc83596d51d15a6808c41afb3fd2
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2095872
Reviewed-by: Mark Mentovai <mark@chromium.org>
This reverts commit dbd454dbe4.
Reason for revert: The parent CL is causing breakage on CrOS due to
unhandled enums. Before we can revert that, we need to revert this.
Bug: google-breakpad:812
Change-Id: I7c2446f3cd8ed9f6411e90dbdd2434bc463b2f6c
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2095798
Reviewed-by: Mark Mentovai <mark@chromium.org>
Previously, dump_syms produced warnings whenever a DW_AT_specification
or DW_AT_abstract_origin attribute was a forward reference. 47cd498384
allowed those attributes to carry forward references, removing the
warnings altogether. It was not correct to remove the warnings entirely.
References that do not point to valid DIEs should still produce
warnings, whether a back reference or a forward reference.
This reintroduces those warnings as appropriate.
Bug: google-breakpad:813
Test: dumper_unittest SimpleCU.UnknownAbstractOrigin,Specifications.BadOffset
Change-Id: Ie7222c7a1886bab31423f27e2fbcce93e69625b3
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2090103
Reviewed-by: Mike Frysinger <vapier@chromium.org>
- "sym-upload-v2" protocol now supports specifying a symbol file "type".
- Known types are "breakpad" (default option, previously this was only
effectively the only option), "elf", "pe", "macho", "debug_only", "dwp",
"pdb", and "dsym".
- When type other than breakpad is specified, sym_upload tool requires
the code_file and debug_id value (that it otherwise would have gotten
from the text of the Breakpad symbol file).
- This ultimately means that sym_upload can be used to upload native
symbol files now, in addition to Breakpad symbol files.
Change-Id: I3a331ba16f199d1d0025df735716ba5de298f522
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2078670
Reviewed-by: Mark Mentovai <mark@chromium.org>
- Didn't used to support statically linked libcurl, now it does (like
HttpUpload does).
Change-Id: Ic014548225b129f0c1c9ffe6a671f5bd2352b6e6
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2068947
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Previously, the processor truncated the upper of two
overlapping module ranges to compensate for incorrect
reporting of module ranges by the Breakpad client.
Crashpad correctly reports module load ranges, so
this truncation strategy is no longer necessary.
However, when partitioned libraries are used, the base
library may have a range which encompasses the other
partitions. When this is combined with the truncate
upper merge strategy, the base library's executable
segment is truncated causing symbolization failures.
This patch changes Android's merge strategy to truncate
the lower range (which is still the base library, but
this strategy truncates from the high end of the
library's range, instead of its base).
Bug: b/149845120
Change-Id: Ic75ecd3e919432690740eb21ebd4265fc0bbaa86
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2067952
Reviewed-by: Mark Mentovai <mark@chromium.org>
* Renamed convert_UTF.c to convert_UTF.cc
* Enabled to use C++17 for [[clang::fallthrough]] defined in src/common/macros.h
Patch by Hiro Komatsu
Change-Id: I5de7f7dd4c8bf231a004144a5c82828c59ddcfd6
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2026761
Reviewed-by: Mark Mentovai <mark@chromium.org>
Stackwalk can't recover caller's register X30($LR) value by STACK CFI info.
This will lead unwinding stop immediately when fallback to frame pointer unwinder.
This PR will use try to use second last frame to recover register X30($LR) by frame pointer.
And we will give up correction if STACK CFI info doesn't agree with frame pointer info.
Bug: https://bugs.chromium.org/p/google-breakpad/issues/detail?id=808
Change-Id: I50649e3398e268b02ff297e83db21d05705c2a2d
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1992641
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
When __DARWIN_OPAQUE_ARM_THREAD_STATE64 is set (by default when building
for arm64e), fp, lr, sp, pc, and flags (but not x or cpsr) in thread
state are prepended with "__opaque" and intended to be accessed via
supplied getters which may also authenticate pointers. We don't want to
authenticate those pointers (since we expect they may be invalid and
want to recover those invalid values) so access them directly.
Bug: b/140375065
Change-Id: Ibe6c1dbfb5d68a9d350614445fa06d48873f8549
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1986868
Reviewed-by: Mark Mentovai <mark@chromium.org>
