| commit | 2d4385f56c64559c9d09f2f2c0a1636bff9f8402 | [log] [tgz] |
|---|---|---|
| author | John Grossman <johngro@fuchsia.infra.roller.google.com> | Wed Feb 26 13:11:19 2025 -0800 |
| committer | Copybara-Service <copybara-worker@google.com> | Wed Feb 26 13:13:27 2025 -0800 |
| tree | ea8aea721973236d88f7acbc48efacd29593a674 | |
| parent | 0939b584c92ec9b6b1255d921eb4aeed59e967c1 [diff] |
[roll] Roll fuchsia [ulib][concurrent] Create a vDSO compatible version of libconcurrent. Add a new target to `ulib/concurrent` called `concurrent_vdso` which is suitable for inclusion in a vDSO image. `libconcurrent` makes us of a _lot_ on std::atomics. This actually can be an issue when building for ARM64 since some toolchains these days automatically attempt to "outline" calls to the atomics. ARM v8.1 added "LSE" atomics to the instruction set, which can provide performance advantages, but need to be tested for at runtime to maintain full portability. So, compilers sometimes add a call (executed either during startup, or lazily) which will check the processor to see if it supports LSE atomics. Calls to atomics are not inlined, but instead go through a thunk which can be controlled by the result of this test. Unfortunately, none of this works in a vDSO environment. If we wanted to add dynamic support for LSE atomics, the decision to use them (or not) would need to be done when we create the vDSO image, not dynamically. So, on ARM64, we want to pass `-mno-outline-atomics` to suppress this behavior when we build for a vDSO. See also b/398297232 Original-Bug: 398297232 Original-Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/1209085 Original-Revision: d57383f0700c7ab2ac13e919a1c6b7d3f4a6e387 GitOrigin-RevId: 3a2bc7f79d10376f2fd756f1f73ae25b489f2d35 Change-Id: I3fefd30df4edcdd1a598db29bbee4f29d8562535
This repository contains Fuchsia's Global Integration manifest files.
All changes should be made to the internal version of this repository. Our infrastructure automatically updates this version when the internal one changes.
Currently all changes must be made by a Google employee. Non-Google employees wishing to make a change can ask for assistance in one of the communication channels documented at get involved.
First install Jiri.
Next run:
$ jiri init $ jiri import minimal https://fuchsia.googlesource.com/integration $ jiri update
Third party projects should have their own subdirectory in ./third_party.