According to the DWARF4 spec:
The DW_OP_bregx operation has two operands: a register which is
specified by an unsigned LEB128 number, followed by a signed LEB128
offset.
Issue: PLCR-545
According to the DWARF4 spec:
The DW_OP_bregx operation has two operands: a register which is
specified by an unsigned LEB128 number, followed by a signed LEB128
offset.
Issue: PLCR-545
An externally deprecated definition is marked deprecated for external
clients only. This allows the framework implementation to use the
definition without receiving deprecation warnings/errors.
Issue: PLCR-543
These were found by -Wdocumentation-unknown-command, which Clang
disables by default because it’s too noisy. In the case of the
PLCrashReporter code, it continually warns that 'internal' is not a
known command.
Issue: PLCR-543
When plcrash_async_read_addr() was removed in commit 1eb3c7b, the call
sites were not updated properly. plcrash_async_task_memcpy() returns
plcrash_error_t and not kern_return_t.
Issue: PLCR-543
This fixes warnings about the doxygen comments not being in sync with
the attributes on the members. This should be the last of the
documentation comment warnings and -Wno-documentation-deprecated-sync
has been removed.
PLCR-543
This is the last of the documentation warning fixes, so the
-Wno-error=documentation flag is being removed and documentation
warnings will be errors from here out.
Issue: PLCR-543
This leaves a handful of warnings about using '@sa @ref async_safety'.
Clang thinks that the '@sa' command has an empty paragraph in this
case, but it appears to be a false positive and a bug in Clang.
Issue: PLCR-543
Given that the project builds with -Werror, the documentation comment
warning has been forced to stay a warning via -Wno-error-documentation.
When the project is free of documentation warnings, this should be
removed.
Warnings about documentation comments containing @deprecated but the
actual declaration not having a deprecated attribute have been disabled
via -Wno-documentation-deprecated-sync. Turning this on and fixing the
warnings will result in a cascade of new warnings relating to using
deprecated APIs.
Issue: PLCR-543
We missed a number of .align statements in the arm64 port. This happened
to work anyway, but in a few cases, misalignment is now triggering
linker warnings, alerting us to the bug.
This adds missing .align directives for all ARM64 code, and also fixes
an innocuous over-alignment (.align 4) for 32-bit ARM.
Issue: PLCR-542
* commit '2b3b33a4d346c84fd8653e1e9e002cdd281e4a6e':
C++11 fix: Add explicit static casts for cases where were relying on implicit conversion to a narrower/signed/unsigned integral type.
C++11 fix: Avoid casting the SIG_* function-types to (in theory) constant uintptr_t values.
C++11 fix: An explicit instantiation must be declared within the template's namespace.
Switch all targets to clang/C++11.
We rely on -fno-exceptions to avoid creating runtime link dependencies
on the C++ stdlib in our static library targets.
When building against the Simulator platform SDK, however, the
"Enable C++ Exceptions" project setting is ignored, breaking linking
of our static libraries in applications that do not not already
link libc++.
This is caused by broken compiler flag configurations in Xcode's
iPhoneSimulator.platform compiler specs; the compiler specs refer to a
legacy "GCC_ENABLE_EXCEPTIONS" flag that is no longer set by Xcode.
To work around this, we add "GCC_ENABLE_EXCEPTIONS" as a user-defined
build setting for the Simulator static library target, with a value
of NO. This hack should be removed once we stop supporting Xcode
releases with a broken Native Build System.xcspec; if the configuration
is not removed, however, it will likely operate as a no-op.
On the remote chance that the configuration does negatively impact the
build in a future Xcode release, it will only affect the simulator
targets.
Issue: PLCR-538
Clang complains about the use of SIG_DFL/SIG_IGN in a switch case; while
they are implemented as integer constants cast to function pointers,
Our casting them back for use in a switch() statement is not strictly
well-defined, so I've switched them to the more correct if () statements.
Issue: PLCR-538
This allows us to use a common code path for fetching the process info,
rather than having a test-only code path that does not safely handle
UTF-8.
If we change the unit test's product name (as per the PLCR-532
reproduction case) to UTF-8 that triggers the multibyte sequence
truncation bug, this change allows the PLCrashLogWriterTests to complete
successfully.
Issue: PLCR-532
* commit 'ecd405532bd12b814339fc9f76b7116fac50e981':
Clarify the comment describing termination within an invalid sequence.
Use strlen() directly.
Additional tests and and memory over-read validation.
Remove unnecessary macro argument in LEN_UTF8() macro.
Add missing nil checks for process name values.
Document that the process name values may be nil.
Log the target pid when fetching the process name fails.
Use the new UTF-8 multibyte truncation handling to clean up p_comm values.
Implement API for trimming incomplete UTF-8 multibyte sequences from a truncated UTF-8 string.
Stub out an API for determining the length, in bytes, of the valid UTF-8 sequences in a string.
This adds a few improvements recommended by Mike Ash:
- Tests for 0-length strings, as well as strings that start with
invalid byte sequences.
- A minor rework of the tests to lay out the test string bytes at the
end of a page, directly before a PROT_NONE page. This allows us to use
page protections to assert that over-read does not occur.
Issue: PLCR-532
This ensures that the inability to fetch or decode the process name (eg,
due to use of invalid UTF-8) won't trigger a crash at crash reporter
initialization time.
Ideally, this code would be unit tested, but that will require
significant changes to the PLCrashLogWriter; in the interests of
regression avoidance, we'll revisit larger-scale API changes as part of
the general refactoring of this code scheduled for the next major
update.
Issue: PLCR-532
Landon Fuller
Joe Ranieri