Imported from GitHub PR https://github.com/abseil/abseil-cpp/pull/1929
`ComputeStackFrameSize` returns `ptrdiff_t` which is `long` while `sizes[n]` is `int`.
This would become an error in chromium build as chromium enables warnings_as_error by default.
Merge ad1d6805b5 into f040e96b93
Merging this change closes#1929
COPYBARA_INTEGRATE_REVIEW=https://github.com/abseil/abseil-cpp/pull/1929 from kxxt:riscv-int-conversion ad1d6805b5
PiperOrigin-RevId: 802286490
Change-Id: I39526e7f9cc26302a18d329989a6b36ddd487f7c
Together with the frame sizes already being returned, this gives us the bounds on each stack frame.
Note that this may slightly affect MSVC in debug builds, as it does not respect ABSL_ATTRIBUTE_ALWAYS_INLINE without optimizations. To remedy this, either enable inlining (/Ob1 or higher), or write a wrapper that ensures any stack traces obtained are robust to frames being added (such as by manually filtering everything below the caller).
Do not depend on the new APIs publicly. They are subject to change or removal.
PiperOrigin-RevId: 740075920
Change-Id: I6cd0909e7be3af4c9f32d39633230f655946b6a8
Imported from GitHub PR https://github.com/abseil/abseil-cpp/pull/1783
Today we cannot build V8 (which uses the Abseil library) in strict mode for RISC-V due to a few warnings in debbugging inlines. All the warnings are about implicit signed to unsigned conversion and precision losses, nothing serious, but they are still very annoying.
Merge 7b2a865021 into 8596c6e7f5
Merging this change closes#1783
COPYBARA_INTEGRATE_REVIEW=https://github.com/abseil/abseil-cpp/pull/1783 from apavlyutkin:riscv-fix-warnings 7b2a865021
PiperOrigin-RevId: 693802454
Change-Id: Ibfefc9370606a6b8ec217ac6d87d7c6d70d1a3ce
In the case that we are unwinding with context, if the retreived frame pointer
matches the signal context, assume that the value is valid and do not perform
confidence checks. In any other case, continue to perform some validation to
avoid returning an incorrect frame pointer.
Given that the VDSO path is currently untested, remove the code to simplify the
logic in the frame walking.
PiperOrigin-RevId: 465360612
Change-Id: Iac656012182a12814bafecf20225ba68b90b4db1
The changes in d6f96eda14 enabled handling cases
where the stack may be non-contiguous or not fully symbolicated (e.g. in cases
of alternate signal stacks). However, it did not properly honour the requests
from the caller to perform a strict unwinding where such frames are terminated
upon the discontinuity. This repairs that condition.
Hoist the alignment check since that is safe to perform early.
PiperOrigin-RevId: 464160529
Change-Id: Ic65645928ec60c2a3b4844f3abd4fed1b991edab
Add a hook to permit checking whether an address is in bounds for the stack.
PiperOrigin-RevId: 460997074
Change-Id: Ib3b4d0cf656e614aa083457abb079c40ef8db0ff
This seems to have caused some regressions by causing a flaky failure in some
cases. Revert the change to enable investigation.
PiperOrigin-RevId: 459331687
Change-Id: Iaa4e4bfcb3013a75a2cd72768d980ac5e450f70c
The alternate signal stack may be sufficiently beyond the esimated frame size
(100k). If we run into the case that the frame is not in the correct direction
assume that the frames may be non-contiguous due to an alternate signal stack
layout. In such a case, if we find that there is an alternate stack configured,
ignore the discontiuity (assuming that it is a removable point-wise
discontinuity) and continue the stack unwinding. This permits us to capture
stack traces in more cases.
PiperOrigin-RevId: 458327775
Change-Id: Ia8b461847401492f72a23ba26601c72e0109402c
When we would perform a stacktrace using the frame pointer walking, because we
did the adjustment for the return address separately, we were misaligning the
stack size and frame. Simplify the logic and correct the offset.
The recovered frame pointer provides us with the return address of the current
frame and the previous frame's frame pointer. Subsequently, we decide if we
want to record this frame or not. The value in `next_frame_pointer` already
points to the value from the previous stack frame (that is the next frame
pointer to iterate). As such, the value computed by `ComputeStackFrameSize` is
the value for the current frame. This was offset by one previously.
Take the opportunity to clean up some of the local comments, fixing typos and
splitting up the comments to reflect the lines that they are associated with.
PiperOrigin-RevId: 453744059
Change-Id: If14813e0ac36f327f4b7594472f2222d05c478aa
--
ef2bf829c333f378ecc12f3259e3187cdb75a3d5 by Abseil Team <absl-team@google.com>:
debugging: fix the VDSO symbol name used for unwinding on RISC-V Linux
The name listed in `man vdso` is incorrect. Instead, use the name from `linux-5.16/arch/riscv/kernel/vdso/rt_sigreturn.S`
PiperOrigin-RevId: 439654174
Change-Id: Ib39d066f416681720068e806e828a2c76a14a532
--
43dfad824afd36cfc3e5049b4fea71a2bccb066c by Benjamin Barenblat <bbaren@google.com>:
Check printf format strings in str_format_convert_test
Add ABSL_PRINTF_ATTRIBUTE to appropriate functions in
strings/internal/str_format/convert_test. Correct
TypedFormatConvertTest.Char, which was accidentally passing values of
types larger than int to StrPrint.
PiperOrigin-RevId: 439388148
Change-Id: I6cde4e8e0c6455064138192430f07f4c990be0bc
--
f84b4ab2c3b070c8af0c82742ac7a8a4bf443bca by Derek Mauro <dmauro@google.com>:
Use __builtin_memcmp in the absl::string_view implementation
starting with MSVC 16.9, where it first appeared
This enables more constexpr operations
PiperOrigin-RevId: 439317316
Change-Id: Iaf1ce76b60901d4b2d5b96be5900c56572f57b15
GitOrigin-RevId: ef2bf829c333f378ecc12f3259e3187cdb75a3d5
--
389189dbb322df0d0468ab13edf7dc185dc63833 by Abseil Team <absl-team@google.com>:
absl str_format.h can compile with -Wconversion and -Wsign-compare
PiperOrigin-RevId: 420799960
--
762e5adc429fc143756c42fe92fe8073c87c075f by Abseil Team <absl-team@google.com>:
GetStackTraceWithContext: Fix min_dropped_frames when no frames are recorded
Previously, if there were still frames to skip, they would be included
in min_dropped_frames.
PiperOrigin-RevId: 420766341
--
7d4374b8eaa410f4f98ec03d6a8997dccadfb271 by Abseil Team <absl-team@google.com>:
absl::flags compiles with -Wconversion and -Wsign-compare
PiperOrigin-RevId: 420476807
--
5f00f7805419d725fa1ff57b388e4c0750d1d6b0 by Derek Mauro <dmauro@google.com>:
Internal change
PiperOrigin-RevId: 420282152
--
bd5471fc34956acf3888bf90287b2aee4415c96d by Derek Mauro <dmauro@google.com>:
Internal change
PiperOrigin-RevId: 420282033
--
61c78020804e4290e9b2fe151aeaf99b198716ee by Derek Mauro <dmauro@google.com>:
Internal change
PiperOrigin-RevId: 420281867
--
dbe3aad24b65ea11664401a307ea3d2f28e8a7b9 by Derek Mauro <dmauro@google.com>:
Remove the incorrect test for the availability of [[nodiscard]]
It should have been ABSL_HAVE_CPP_ATTRIBUTE(nodiscard) instead of
ABSL_HAVE_ATTRIBUTE(nodiscard). As a result, some code is not
compliant with [[nodiscard]], so we cannot simply correct the availability
test.
Recommend that C++17-only code use the standard [[nodiscard] directly.
PiperOrigin-RevId: 420150702
GitOrigin-RevId: 389189dbb322df0d0468ab13edf7dc185dc63833
Change-Id: Idf6ebae3c4edd945c9032c7db3d0ab32d16e8078
--
04cb3b22497190170aa5b774e98080c5de2ba60b by Abseil Team <absl-team@google.com>:
Alternative bit mixer for LowLevelHash on ARM
LowLevelHash's bit-mixer is inefficient on ARM because it calculates a 128-bit product of two 64-bit numbers. On ARM, this requires a sequence of two instructions with a high combined latency and poor throughput. This change provides alternative bit-mixing code for ARM that uses only 64-bit arithmetic (multiplication, xor, and left-shifts) and speeds things up considerably.
The bit-mixing code for ARM was inspired by by Woothash[1] and xxh3[1]. Once I landed on a sequence of operations that provided good mixing, I used a test harness to search for the combination of shift / rotate factors that provided the best mixing, as indicated by SMHasher hash quality tests. The new mixing code passes 13 out of 15 of the hash quality test suites in SMHasher, with the two failures being in the noise range: e.g. 1 collision vs. zero expected in a keyset of ~8m keys.
[1]: https://github.com/tommyettinger/waterhash/blob/49f5cf0b63b9/woothash.h#L16-L20
[2]: https://github.com/Cyan4973/xxHash/blob/6853ddc36e46/xxhash.h#L3240-L3265
PiperOrigin-RevId: 391833008
--
17a4de1f9d623155c75b19285d414cd55a487cd6 by Saleem Abdulrasool <abdulras@google.com>:
debugging: add support for unwinding on RISCV Linux
This adds partial support for unwinding the RISCV call stack. It is largely
duplicated from the AArch64 support with alterations for the ELF RISCV psABI.
This covers RISCV64 and RISCV32, though not the ILP32E calling convention.
PiperOrigin-RevId: 391818522
--
32c93e449327b2cea32b32f6365e84b420fe1ed3 by Gennadiy Rozental <rogeeff@google.com>:
New storage for types smaller than 8 bytes.
Also adding new read interface for types smaller than or rqual to 8 bytes to avoid passing the pointer.
PiperOrigin-RevId: 391726822
--
e987ac08a7787801cbfc7d7c96649e97fa8cff1a by Abseil Team <absl-team@google.com>:
Extern template `find_first_non_full` to reduce linkage size for TU with single not inlined function.
PiperOrigin-RevId: 391718862
--
73af9bfcb5bf045089133e18bbd20eb5bb699172 by Gennadiy Rozental <rogeeff@google.com>:
Make most non-mutable most int128 methods and friend free functions constexpr.
Some functions are implemented offline (at least in some configurations) and can't be made constexpr. Mutable methods can't be made constexpr until we drop c++11 support.
Fixes#978
PiperOrigin-RevId: 391706535
GitOrigin-RevId: 04cb3b22497190170aa5b774e98080c5de2ba60b
Change-Id: If051fad5ff004e2e82fa53618fc04a6fe3d2d4be
