The big-endian PowerPC ELF ABI (ppc64 in Debian) relies on function
descriptors mapped in a non-executable segment. Make sure that segment
is scanned during symbolization. Also correct bounds computation for
that segment.

PiperOrigin-RevId: 544440302
Change-Id: Ic05532aa35ae9efa127028318640ee7cdeeecc5f

PiperOrigin-RevId: 544438364
Change-Id: I22d461f2d0aa8638a0e640eebecdc7e5e2b49ea3

PiperOrigin-RevId: 544401753
Change-Id: Ie5bb48bb46c8c1bf41ef902242cefefd739e7c37

Introduce a kTotalMorePrecise accounting mode for Cord::EstimatedMemoryUsage(). This mode avoids double-counting blocks that a Cord references more than once; otherwise it is similar to the existing kTotal mode.

There's no change to the existing kTotal or kFairShare accounting modes.

PiperOrigin-RevId: 544378591
Change-Id: I7b4ae55cd93d631194e59a9cd0ff07f47611219e

PiperOrigin-RevId: 544197983
Change-Id: I7eb39563e696d6561ad193d4d25b4161eb6419ae

PiperOrigin-RevId: 544146637
Change-Id: I5ca44465f451956ae246081ce826891599b18b9c

PiperOrigin-RevId: 544107572
Change-Id: I8016ee690ad5df78bf80ba0786e528fba4e51907

PiperOrigin-RevId: 544060862
Change-Id: I6ca631385826f6e10f6c3eeec1af532402d0b532

PiperOrigin-RevId: 543896343
Change-Id: Ia91b3e082b764b750bbbe9a3ce63192263d51438

Previously this was guarded with macros that are defined by <bit> itself.

Note that libc++ also had a bug that was fixed last week
https://github.com/llvm/llvm-project/commit/a4f0764aefd6ea41e83a5974f582a1a7e985667d

PiperOrigin-RevId: 543511181
Change-Id: I1b8efa32f721ad450f8d1803c6c6c8373ad0371c

This trick was introduced to work around a compiler bug in msvc 2017, which abseil doesn't support anymore: https://github.com/google/oss-policies-info/blob/3aa4b98f497fdfac983b8de78cf6bd693cb0cf4f/foundational-cxx-support-matrix.md

PiperOrigin-RevId: 543477428
Change-Id: I332c1b359b75811536ce900d3166979ac3c196a3

It's NOOP without HWASAN.

PiperOrigin-RevId: 543045322
Change-Id: Ibb5f28d316bfc5e8aa51861fd55e50ecb517a9a3

PiperOrigin-RevId: 542269673
Change-Id: Ib6f7e9a57f83d73dd6fb9c45fc9f85ff0fdd75fe

Check various corner cases for Await/LockWhen return value
with always true/always false conditions.
I don't see this explicitly tested anywhere else.

PiperOrigin-RevId: 542141533
Change-Id: Ia116c6dc199de606ad446c205951169ec5e2abe1

Currently linter warns on all changes:

missing #include <cstdlib> for 'std::atexit'

and

single-argument constructors must be marked explicit to avoid unintentional implicit conversions

Fix that.

PiperOrigin-RevId: 542135136
Change-Id: Ic86649de6baef7f2de71f45875bb66bd730bf6e1

Fixes #1482

PiperOrigin-RevId: 542023050
Change-Id: Iba712083edc9a24732a71f51be22ea970115809c

Fixes #1479

PiperOrigin-RevId: 542022998
Change-Id: I9d6059341fe867ad5539ef2a4d57925858a9cfc0

Few pure cosmetic changes:
 - remove unused headers
 - add using for CycleClock since it's used multiple times
 - restructure GetMutexGlobals to be more consistent

PiperOrigin-RevId: 542002120
Change-Id: I117faae05cb8224041f7e3771999f3a35bdf4aef

Reformat Mutex-related files so that incremental formatting changes
don't distract during review of logical changes.
These files are subtle and any unnecessary diffs make reviews harder.

No changes besides running clang-format.

PiperOrigin-RevId: 541981737
Change-Id: I41cccb7a97158c78d17adaff6fe553c2c9c2b9ed

PiperOrigin-RevId: 541915097
Change-Id: I7ebfbafc36db38b59b30ab5b312cd7e22082a805

PiperOrigin-RevId: 541111597
Change-Id: I88165130e30e548a03d8d6173dadab33dc18b21e

PiperOrigin-RevId: 540928490
Change-Id: Idf022b28ce101a948be4efd5336888a66f5eacf9

Currently when we queue the first thread, we don't init its priority.
Subsequent queued threads init priority, but they compare it against
the first thread priority, which is uninit. Thus the order can be wrong.
It can lead to complete false starvation in some corner cases.

On Linux the default priority is 0, which matches the uninit value,
thus the problem is harder to spot on Linux (only possible if explicit
thread priorities are used). But on Darwin the default priority is 31,
thus the first thread falsely looks like lower priority than subsequently
queued threads. The added test exposes the problem on Darwin.

Always initialize the priority before queuing threads.

PiperOrigin-RevId: 540814133
Change-Id: I513ce1493a67afe77d3e92fb49000b046b42a9f2

Move the comment that relates to kMuDesig close to kMuDesig definition.
Currently it's placed in between unrelated flags.

NFC

PiperOrigin-RevId: 540792401
Change-Id: I5f6a928cd9e01664812b2a7c3d9eb087c0723d7f

which makes it give up in certain situations where the x86 handler works
fine

This change adopts x86's more sophisticated stack-bounds-checking
method for aarch64, and enables the HugeStack test to pass on aarch64.

PiperOrigin-RevId: 540655431
Change-Id: If7d816330327722bbe5c135abfa77fda5e7e452b

It no longer strictly writes to stderr, since Emscripten/WebAssembly now use _emscripten_err which might be replaced by something that is not the same as stderr by the host.

PiperOrigin-RevId: 540655336
Change-Id: Icc2a430a0db53a1282ef5558e9f3648db67e972c

PiperOrigin-RevId: 540586646
Change-Id: Iac1e133647fbaa5036ac9ef7322f9af5886c658e

This bypasses the need for filesystem APIs just for stderr access.

PiperOrigin-RevId: 540367155
Change-Id: Ib91dadac28cb5c8e571407b5dfa60c3e65539c95

PiperOrigin-RevId: 539960446
Change-Id: If2de8bf32ffeed849280f78f8ac0685e11e80f59

PiperOrigin-RevId: 539900072
Change-Id: I675386e3184f6f5ab70b851add970c91d1dde9c5

PiperOrigin-RevId: 539784770
Change-Id: Ie224afa04af023bbddc89b967e8c8440f9e8a887

implementation.

PiperOrigin-RevId: 539749773
Change-Id: Iec83431ffd360a077b153cea00427580ae287d1f

PiperOrigin-RevId: 539747818
Change-Id: Ia0ab0fdda0ffe9b23d83d55c899f301df20b1179

PiperOrigin-RevId: 539726003
Change-Id: Ie38f8d48a7b4c9d498fc1c4c4af6138048f80f68

This is a conservative change, in that it only contains bugfixes and allows new patterns that used to be compile errors.  There are other changes we would like to make (as reflected in the comments in char_formatting_test.cc), but we are being careful about the implications of such behavior changes.

The two implementation changes are:
* Apply integral promotions to enums before printing them, so they are always treated as integers (and not chars) by StrCat and StrFormat.
* Classify `unsigned char` and `signed char` as integer-like rather than char-like, so that `StrFormat("%v", v)` accepts those types as integers (consistent with `StrCat()`.)

The behavior changes are:
* StrCat() now accepts char-backed enums (rather than failing to compile).
* StrFormat("%v") now accepts `signed char` and `unsigned char` as integral (rather than failing to compile).
* StrFormat("%v") now correctly formats 8-bit enums as integers (rather than failing internally and emitting nothing).

Tested:
  Modified the char_formatting_test.cc case to reflect changes.
  Re-ran all other tests.
PiperOrigin-RevId: 539659674
Change-Id: Ief56335f5a57e4582af396d00eaa9e7b6be4ddc6

off_t is best for portability. Its size varies with the platform.
off64_t is non-standard, but is present in glibc and some BSDs.
It also matches the signature specified in the manual.
https://man7.org/linux/man-pages/man2/mmap.2.html

This is a re-spin of #1349, but correctly casts the type to the type
expected by the kernel for mmap2.
https://man7.org/linux/man-pages/man2/mmap2.2.html

Fixes #1473

PiperOrigin-RevId: 539656313
Change-Id: I7a30dd9d3eb6af03a99da0d93d721a86f6521b25

AppleClang seem to allocate two extra 64-bit words per each `new[]`.

A test should pass larger buffer to a placement `new[]`.

Fixes #1090

Introduce kHighRefcountMask which masks off flags and the LSb of the refcount value. In the cases where this mask is used, we don't need to check the LSb because we can assume the refcount is 1 when the rest of the masked RefcountAndFlags is empty, and the LSb doesn't matter if the masked value is not empty (either it's immortal or refcount > 1). This saves an instruction and a cycle (and + cmp -> tst) https://godbolt.org/z/Kz69eqfhq

PiperOrigin-RevId: 539151659
Change-Id: I2ec7d72918f052c4b0938edd746af9d5b3052c7e

PiperOrigin-RevId: 539145188
Change-Id: Ic8dc8112f77ca720a8871de57ee389f15693ab00

This fixes an endless loop in the absl Arm stack unwinder where encountering a
second signal return trampoline (as one has in nested signal frames), would restart
unwinding at the outermost signal, resulting in an endless loop.

This does not change any behavior in the non-nested signal case, so I believe
it is safe for any stack that hasn't encountered this bug already.

I would love to test this beyond the absl unwinding test cases and the
fingerprint_test included here, but I'm at a loss for other test cases.

PiperOrigin-RevId: 539113007
Change-Id: I10037f9fa77b45cc4db61f89b9c6380ec3529113