This implements four modules (static/shared/header libraries, and
binaries) for vendor snapshot. These modules will override source
modules if BOARD_VNDK_VERSION != current.
Bug: 65377115
Test: 1) VNDK_SNAPSHOT_BUILD_ARTIFACTS=true m dist vndk vendor-snapshot
Test: 2) install snapshot under source tree
Test: 3) set BOARD_VNDK_VERSION and boot cuttlefish
Change-Id: I24ddb4c3aa6abeab60bbfd31bcbd8753e2592dc5
Vendor snapshot can be captured with "m dist vendor-snapshot". With
vendor snapshot and vndk snapshot, older version of /vendor and newer
version of /system will be able to be built together by setting
BOARD_VNDK_VERSION to past vendor's version.
Only vendor modules under AOSP are to be captured. In detail, modules
under following directories are ignored:
- device/
- vendor/
- hardware/, except for interfaces/, libhardware/, libhardware_legacy/,
and ril/
Test modules (cc_test, etc.) and sanitized modules are also ignored.
Bug: 65377115
Test: m dist vendor-snapshot
Change-Id: If7a2f6de7f36deee936930c0ccf7c47c4a0cebf6
Build fuzzer-sanitized libraries with an $ORIGIN DT_RUNPATH. Android's linker
uses DT_RUNPATH, not DT_RPATH. When we deploy cc_fuzz targets and their
libraries to /data/fuzz/<arch>/lib, any transient shared library gets the
DT_RUNPATH from the shared library above it, and not the executable, meaning
that the lookup falls back to the system. Adding the $ORIGIN to the DT_RUNPATH
here means that transient shared libraries can be found colocated with their
parents.
This may have some interesting consequences if:
1. Your fuzz target depends on a shared library which has `sanitize.fuzzer:
false` (as the DT_RUNPATH won't have `$ORIGIN`, and so you may get missing
libraries).
2. A `SANITIZE_TARGET=fuzzer` platform has a shared object in two
different directories (like system vs. ndk) and is depending on the linker
implementation details to resolve this in some manner.
I don't believe either of these instances should reasonably happen in
practise.
Fixes: 145973404
Fixes: 145988908
Test: m example_fuzzer
Change-Id: I94cbf628fc1ce15c43283d72bdabd9817de1fef8
This is a workaround to improve hwasan reports involving stack
variables.
Bug: 112437883
Test: SANITIZE_TARGET=hwaddress, build and boot
Change-Id: I21ea2fdd2d1f04e2bb9b9847785c00a951030c74
Prepare for making the image mutator available to all modules and
moving it between the os and arch mutators by moving it into the
android package and using an interface implemented by the module
types to control it.
Bug: 142286466
Test: No unexpected changes to out/soong/build.ninja
Change-Id: I0dcc9c7b5ec80edffade340c367f6ae4da34151b
Native compiler flags are currently applied in approximately:
global cflags
local cflags
local include dirs
global include dirs
global conlyflags
local conlyflags
global cppflags
local cppflags
This means that a flag that is enabled in the global cppflags
cannot be disabled in the local cflags, and an Android.bp author
must know to disable it in the local cppflags. A better order
would be:
global cflags
global conlyflags
global cppflags
local cflags
local conlyflags
local cppflags
local include dirs
global include dirs
We are mixing both the global and local cflags into a single
variable, and similar for conlyflags and cppflags, which
prevents reordering them. This CL prepares to reorder them
by splitting the global and local cflags into separate variables.
Bug: 143713277
Test: m native
Change-Id: Ic55a8c3516c331dc5f2af9d00e59ceca9d3e6c15
This is a follow-up CL of I9a24f6975bd4b226a94f61a13d43857dcdce6b88
Generated files are passed to make via MakeVars:
- SOONG_LLNDK_LIBRARIES_FILE
- SOONG_VNDKCORE_LIBRARIES_FILE
- SOONG_VNDKSP_LIBRARIES_FILE
- SOONG_VNDKPRIVATE_LIBRARIES_FILE
- SOONG_VNDKCOREVARIANT_LIBRARIES_FILE
- SOONG_VNDK_LIBRARIES_FILE
Previously filenames were "guessed" from module names. Now VndkMutator
stores filenames as well and generate those files with them.
Bug: 142963962
Bug: 141450808
Test: m && device boots && TH
Change-Id: I0c248b707188f904df60ead50059fefe90bfd17f
Adds the ability for rust modules to be compiled as C libraries, and
allows cc modules to depend on these rust-generated modules. This also
means that soong-rust should not have any dependencies on soong-cc aside
from what's required for testing.
There's a couple small fixes included as well:
- A bug in libNameFromFilePath that caused issues when library's had
"lib" in their name.
- VariantName is removed from rust library MutatedProperties since this
was unused.
Bug: 140726209
Test: Soong tests pass.
Test: Example cc_binary can include a rust shared library as a dep.
Test: m crosvm.experimental
Change-Id: Ia7deed1345d2423001089014cc65ce7934123da4
Adds an interface, CcLinkableInterface, for cc linkable dependencies
which come from other toolchains such as Rust.
Bug: 140726209
Test: Soong tests pass, rust modules still compile.
Change-Id: I7378a46fad94fd0b735746aaf4e265fd2c2c04d8
libdl.a has a no-op dlopen, which breaks static libraries that need a real
dlopen. Instead of automatically linking libdl.a into static executables,
make it optional.
Until recently, the libunwind_llvm.a unwinder, used on arm32, needed the
no-op dladdr, but it's now built using -D_LIBUNWIND_USE_DLADDR=0.
The HWASan run-time uses dlsym and dladdr, so add a libdl dependency for
HWASan-built static binaries. We could also remove the dependency from
libclang_rt.hwasan_static-*.a, but this is also easy to do.
Bug: http://b/141485154
Test: bionic unit tests, device boots, verify that static and dynamic
executables can throw/catch an exception
Test: verify that a static executable using dlopen doesn't link (unless it
adds an explicit dependency on libdl)
Change-Id: Ic52c3f336b671b4ed335e99c94a64dfe8614b618
The arch variants are hardcoded in every module type. Refactor
them out into a Target.Variations() method in preparation for
splitting the arch mutator into two, which will require using
different variations.
Test: m checkbuild
Change-Id: I28ef7cd5168095ac888fe77f04e27f9ad81978c0
Fuzz targets currently have dependencies on multiple libclang_rt runtime
libraries when building with ASan/HWAsan on device. This is an error.
This happens as Soong adds the dependency on the ASan/HWASan shared
runtime library. These libraries should provide the required UBSan
components. The clang driver was previously being passed
-fsanitize=fuzzer-no-link at link time, and as it doesn't know about the
already-established dependency on ASan/HWASan, it mistakenly thinks that
there is not runtime providing the UBSan components.
This patch fixes that problem by not adding -fsanitize=fuzzer-no-link to
the link-time flags.
This revealed a underlying issue in the upstream runtime compilation.
Android uses emulated TLS, which changes the symbol names from
<my_symbol_name> to __emutls_v._<my_symbol_name>. In particular, this
fails to account for the '__sancov_lowest_stack' symbol, as it no longer
matches the linker script rule for '__sancov*', and the symbol is no
longer exported in the shared library variant of ASan/HWASan.
This patch works around the discovered issue, which is being tracked in
the linked bug. It disables stack depth instrumentation, and we no
longer depend on this symbol. This means we get a missing sanitizer
coverage feature when fuzzing, but shouldn't be too detrimental.
Bug: 142430592
Test: SANITIZE_TARGET=hwaddress m example_fuzzer && \
readelf -d example_fuzzer # ensure only ONE libclang_rt dep (in this
case, hwasan)
Change-Id: Iea6df55d592a801732511c9b690134367429d62a
Without this change, we can end up failing to sanitize parts of libraries
that are compiled as cc_objects, such as bcm_object.o in boringssl. This
is normally harmless (except that the sanitizer would fail to detect bugs
in unsanitized code), however boringssl in particular needs to be compiled
with HWASAN enabled in all translation units in order to avoid link errors
with newer toolchains that support HWASAN global instrumentation.
Change-Id: Ib8bd325f76b7852cab435bff79d6945768298a5c
Disables FORTIFY for fuzz target builds. We generally build with a
sanitizer and want the sanitizer to handle the bugs and provide us with
a nice stack trace.
Bug: 140187921
Test: m example_fuzzer && $ANDROID_HOST_OUT/fuzz/example_fuzzer (note
that you get a proper ASan report instead of a fortify crash)
Change-Id: I15a117b26c401a03785fb44c0f796588f366bc55
This reverts commit cba311bcfc.
The build is actually still broken with ASAN globals instrumentation.
We accidentally suppressed ASAN by turning on the new pass manager and
the build breakage was not discovered.
Bug: 137312732
Bug: 139747256
Change-Id: I8110e1413468c4d760a59a8de816a72c9852a7c8
ASAN build has some weird issues with the new pass manager, keep using
the legacy pass manager for now.
Test: presubmit
Bug: 139747256
Change-Id: I345afbf6bc4043f274a4e7545a895b59c65641b0
This change fixes a problem in sanitizerMutator where a module is linked
with of non-sanitized variant of a lib at build-time, but is linked with
the sanitized variant of the lib at run-time.
This happened because, for each sanitizer type, every shared libs are
split into non-sanitized and sanitized variants, and then either of the
variants are suppressed from Make so that it isn't installed to the
device.
This change fixes the problem by NOT splitting for shared libs; only the
sanitized variant is created if needed. Header libs, static libs and
shared libs for a few sanitizer types (asan/fuzzer) are however split
into two. This is because the static and headers libs become part of the
depending module, and asan/fuzzer require that the depending module and
the dependant module should be compiled for the same sanitizer.
Bug: 138103882
Bug: 138426065
Test: m com.android.runtime.debug
Check that libziparchive exists under both
/system/apex/com.android.runtime/[lib|lib64]
Change-Id: Ia447785c485c0d049e19477b32bc638bfe6f1608
Bug: 131771163
LTO is currently broken when building with SANITIZE_TARGET=fuzzer. The
compiler bug is currently being addressed upstream (see linked bug), but
we have applied a local workaround in the build system to disable LTO
when building using the fuzzer config.
There is a bug here however. In the sanitizer mutator we explicitly
remove -flto and add -fno-lto. The sanitizer mutator runs after the LTO
mutator, so (in general) this works just fine. The problem exists when a
target specifies an explicit 'lto: { ... }' flag in their Android.bp. In
this case, the sanitizer mutator disables LTO, then the flags are parsed
from the Android.bp, re-enabling LTO.
This patch fixes this issue. If the sanitizer mutator has added the
-fsanitize=fuzzer-no-link flags, then the LTO mutator won't add the LTO
flags after this fact.
Test: Build a target with SANITIZE_TARGET=fuzzer (or a cc_fuzz target),
where there is an explitiy 'lto: { ... }' and watch it now succeed in
building.
Change-Id: I6643909417f666539c23469816926b806e204b06
We already link the shared prebuilt from the toolchain. This is
redundant and the wrong version.
Test: make checkbuild
Bug: http://b/74067984
Change-Id: I4b5d23514158eebfb4eea2aa6761e076131c3224
ASan globals instrumentation apparently broke the build in the pass.
This is now a customer feature to get this up and running, let's see if
it works.
Bug: 137312732
Test: Build the platform, deploy and run an asan-ified test (maybe
resolv_integration_test?).
Change-Id: Ic4ee0db617c290d8a3fec52db4b90bc4772696b8
sanitizerRuntimeDepsMutator only modifies the currently visited
module, it can visit modules in parallel.
Also, stop recursing into modules that are not static dependencies,
and stop recursing if the module already has all modifications that
the mutator could make.
Test: m checkbuild
Change-Id: I95a57f763a91940f1854ba3c587a2f70e8baba97
Sanitizer coverage is currently broken with the experimental pass
manager. See b/133876586 for more information. The patch is currently
being worked on upstream (https://reviews.llvm.org/D62888), but is not
ready yet. Hence, we disable it here (similar to the LTO bug).
Bug: 133876586
Test: Build anything with SANITIZE_TARGET='fuzzer', verify that it has
'sancov' symbols.
Change-Id: I4302a8cf05300015aaff137f40b61d5685dc3fea
Current Android toolchain does not support hwasan with new pm.
Bug: 135298400
Test: manual, inspect the binaries for calls to __hwasan_init
Change-Id: I126c59e6ecabc3a1699e1bf34c546568b6e8a21f
- Updates the fuzzer builds to use SANITIZE_TARGET='fuzzer' instead of
'coverage'.
- Removed an old dependency that made fuzzer builds without ASan
an error.
- Fixed up the build flags to allow fuzzers to be built. Previously, the
coverage flags were manually provided. As the toolchain has moved on,
these flags are no longer compatible with libFuzzer, and so I've updated
them to use the correct, compatible flags.
- Added a dependency mutator for fuzzer coverage.
Bug: 121042685
Test: With all patches in the bug merged, build a fuzzer using
'SANITIZE_TARGET=fuzzer mmma <your_fuzzer>'.
Change-Id: Ib6246980f77bc4babe587b1e88038aa12228fa83
Merged-In: Ib6246980f77bc4babe587b1e88038aa12228fa83
- Updates the fuzzer builds to use SANITIZE_TARGET='fuzzer' instead of
'coverage'.
- Removed an old dependency that made fuzzer builds without ASan
an error.
- Fixed up the build flags to allow fuzzers to be built. Previously, the
coverage flags were manually provided. As the toolchain has moved on,
these flags are no longer compatible with libFuzzer, and so I've updated
them to use the correct, compatible flags.
- Added a dependency mutator for fuzzer coverage.
Bug: 121042685
Test: With all patches in the bug merged, build a fuzzer using
'SANITIZE_TARGET=fuzzer mmma <your_fuzzer>'.
This is the qt-dev-plus-aosp cherrypick of aosp/954925. See the AOSP
commit for further information.
Change-Id: Ib6246980f77bc4babe587b1e88038aa12228fa83
HWASan has a feature to fill malloc() memory with non-zero pattern.
This has found a bug or two in the past, but it also keep causing hard
to debug issues. The main problem is lack of diagnostics - use of
pattern-initialized memory is not an immediate crash. More often than
not it manifests as a subtle change in system behavior.
Having MemorySanitizer on Android would be nice...
This change does not affect any shipping configuration, but improves
stability of testing-only SANITIZE_TARGET=hwaddress build.
Bug: 132803232
Bug: 132652537
Bug: 131438232
Bug: 132810685
Test: SANITIZE_TARGET=hwasan on crosshatch successfully boots in ~100%
attempt (up from ~99% currently).
Change-Id: I7dcbcdf1b8a5b8556e32690327b32f04879e5db1
