The feature is pure optimization, but it requires
additional syscalls.
PiperOrigin-RevId: 432954277
Change-Id: I1f345f8a26c86e09611fd575cb6ee080f24cc717
There are a lot of internal users depending on the old behavior of the
libclang-based generator.
PiperOrigin-RevId: 432281224
Change-Id: If82333fc3001f52de59e57a874f28bf8815d0877
The constexpr functions can be used to ensure that all branches actually compile
(unlike plain preprocessor `#ifdef`s).
PiperOrigin-RevId: 432186834
Change-Id: I1a8d97dac8480fe9d4543b0e9e39540ca1efc8fa
munmap is widely used by sanitizer, but it
probably works for Asan/Msan because it's enabled
by unrelated Allow* call.
Move mprotect to shared part as well. It will be
needed for compress_stack_depot.
PiperOrigin-RevId: 431989551
Change-Id: I7695a2de81d8d0b2112d3308778b2e9a9c7cb596
Use [`direct_headers`](https://bazel.build/rules/lib/CompilationContext#direct_headers)
from the Bazel/Blaze compilation context instead of _all_ transitive headers.
For the clang based generator, this means we don't try to parse
`textual_headers`, which will fail (they are by definition not
stand-alone, after all).
PiperOrigin-RevId: 431899423
Change-Id: I7a9dfa0dd93eba14b506b0e7ca6db3ed59b55dd6
This will speed up our builds a bit and prevent unnecessary network traffic.
Setup according to the documentation for the `actions/cache@v2` action:
https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows
Currently caching the `${{github.workspace}}/_deps` directory, as used by CMake.
Cache keys look like this: `ubuntu-20.04-clang11` (`${{matrix.os}-${{matrix.compiler}}${matrix.compiler-version}}`)
PiperOrigin-RevId: 431895214
Change-Id: I4ecac7c00eec8516f85f45aa2220303b811b2389
The default limit for recent versions of Clang is 256 which is less than the
number of syscalls in our syscall tables (around 340). This change increases
this limit to an arbitrary 768.
PiperOrigin-RevId: 429258387
Change-Id: I4927eee78edc8aaa2a758b29811d02326e5aa953
Linking glibc in fully static mode is mostly unsupported. While such binaries
can easily be produced, conflicting symbols will often make them crash at
runtime. This happens because glibc will always (try to) load some dynamically
linked libraries, even when statically linked. This includes things like the
resolver, unicode/locale handling and others.
Internally at Google, this is not a concern due to the way glibc is being built
there. But in order to make all of our tests run in the open-source version of
this code, we need to change strategy a bit.
As a rule of thumb, glibc can safely be linked statically if a program is
resonably simple and does not use any networking of locale dependent
facilities. Calling syscalls directly instead of the corresponding libc
wrappers works as well, of course.
This change adjusts linker flags and sandbox policies to be more compatible
with regular Linux distributions.
Tested:
- `ctest -R '[A-Z].*'` (all SAPI/Sandbox2 tests)
PiperOrigin-RevId: 429025901
Change-Id: I46b677d9eb61080a8fe868002a34a77de287bf2d
