unwinding through tagged frames is fixed in upstream and cherry-picked
onto Android toolchain in https://r.android.com/2251926. until then, we
can disable stack tagging for code that uses exception, so we can get
some coverage before the toolchain update.
Test: stack_tagging_helper exception_cleanup from https://r.android.com/2175188
fails with assertion "GetTag(&y) !=
GetTag(__builtin_frame_address(0))" as expected
Bug: 174878242
Change-Id: I1597b21f64a92874dbccb64ffebbef7bb9bf8214
We regressed binary size when we switch Darwin to use LLD, because
Darwin LD64 does ICF by default. Turn on ICF for host binaries to regain
the binary size savings (saves some space for Linux as well).
Test: presubmit
Bug: 236924555
Change-Id: I433062c3d263d69e431c1552faf1f18b13c5da42
Also disallow arch variant of genrule.out.
This is to be consistent with bazel where we are migrating to.
Bug: 254114674
Test: Manual
Change-Id: I685a2e64102b7bb68128b39931f0bc85878bc6de
There are some module definitions which are implemented for the proof of
concept, but these modules are not in use now. This change removes
unused module definitions to reduce confusion.
Bug: N/A
Test: m nothing passed
Change-Id: I9b8efbc368436eaef66a4e6557006e87c0c27713
Some projects do not allow or fix tidy warnings to
avoid warnings-as-errors. They should not run
clang-tidy even with TIDY_EXTERNAL_VENDOR=1.
Bug: 244631413
Test: presubmit; TIDY_EXTERNAL_VENDOR=1 make tidy-external_subset
Change-Id: Id86a55c222fdad813c1c3434245c86bb97d0cad6
This will avoid suppressing all checks in user defined
.clang-tidy config files.
Bug: 252877310
Test: TIDY_EXTERNAL_VENDOR=1 make tidy-soong_subset
Change-Id: I99032300542e9b83cba60b00f8d328c63b5728e2
Switch from `PathForModuleSrc` to `PathForSource`. The latter does not
check that the target path exists in the tree. This is necessary since
the prebuilt stub and header directories are not guaranteed to exist
when Soong analysis begins (Step 2a)
Build orchestrator will be responsible for putting these files in the
right place as part of Multi-tree ninja invocation (Step 4)
Test: go test ./cc
Change-Id: I27175a8440fca6bba21197b1e106a22b733da882
The build uses unstripped binary/shared library to extract function
signatures, so for each each target of this kind Bazel should return
its unstripped version, too.
Fixes: 220164721
Test: treehugger
Change-Id: Id5f6143340519bf2ae98791a9e981d1306bb08d1
Bug: http://b/248022906
Bug: http://b/247941801
HWAsan global instrumentation on __llvm_profile_filename causes
duplicate symbol errors when linked together with libraries where hwasan
is disabled. Disable hwasan global instrumentation since those type of
errors are rare.
In the future, we may fix this in llvm to skip hwasan global
instrumentation on symbols added for coverage.
Test: m CLANG_COVERAGE=true NATIVE_COVERAGE_PATHS=* \
SANITIZE_TARGET=hwaddress
Test: Add `hwaddress: true` to libc_defaults; m CLANG_COVERAGE=true
Change-Id: I8506cfd567d212262a2a54b9881a8f64cdbf7a76
create_minidebuginfo doesn't support riscv64 yet, disable stripping
for riscv64 until it does.
Test: m ALLOW_MISSING_DEPENDENCIES=true LLVM_PREBUILTS_VERSION=clang-r468909b LLVM_RELEASE_VERSION=15.0.3 libc -k
Change-Id: Iaad7ec0e4befe1652b413e20a7095cdde56d57bc
Enable cc_prebuilt_binary to also take part in mixed builds.
Bug: 241415823
Test: TestPrebuiltBinaryWithBazel
Test: mixed_droid yields stats-log-api-gen under bazel-out/
Change-Id: I18b2906c91ea90370ab851a1287c2890546d633f
Otherwise we hit an unknown --arch error in ndkstubgen as soon as we try
to build an NDK library (such as libc/libdl/libm, which are the very
first libraries we need to build).
Test: treehugger
Change-Id: Id633248d1fa80eeddfd234301355931bb1309dc3
The module types in scope of this conversion are
1. cc_library and cc_library_shared (non-null llndk or stubs prop)
2. cc_library_headers (all)
For (2), we need some postprocessing on the results of the parser
bp2BuildParseBaseProps. This is necessary because arch and os specific
API exports need to be flattened and added to the generateed API headers
target along NoConfigAxis
e.g.
```
The api equivalent of
cc_library_headers (
name = "lifoo",
deps = select({
"//build/bazel/platforms/arch:arm": ["arm_deps"],
"//build/bazel/platforms/arch:arm64": ["arm64_deps"],
}),
)
should be
cc_api_library_headers (
name = "lifoo",
deps = ["arm_deps", "arm64_deps"],
)
```
For (1), we also need to generate 1:many header api targets so that
arch-specific deps can propagate arch metadata to the top-level
api_domain rule
Test: go test ./bp2build
Test: go test ./cc
Change-Id: Ie40cba1ac8e89f290b3d926c190d5e93abd52859
I49220cbec628f1508709741dc56b62aaac7786d9 attempted to allow
apexes to depend on native code whose min_sdk_version had been
increased to meet the minimum supported API level for a new
architecture. It wasn't quite right, as it assumed that the
primary architecture of the apex would be the newest, and
it applied to all dependencies, not just ones that were
specfiic to the new architecture. Move the checking into
cc.ShouldSupportSdkVersion, where it can be specific to an
individual architecture variant.
Bug: 250918230
Test: TestApexMinSdkVersion_MinApiForArch
Change-Id: I303cf485ba54b4c6bf63a9f9b49286ff9b2c9c83
Allow external/vendor owners and toolchain developers
to run clang-tidy with external/vendor files,
by setting TIDY_EXTERNAL_VENDOR=1 or true
instead of touching .bp or .go files.
Bug: 244631413
Test: TIDY_EXTERNAL_VENDOR=1 make tidy-soong_subset
Change-Id: I0c903f32eb0e5daa0f8dfa2f6dc892b8f8c4ebcc
* changes:
Move fuzzer's CollectAllSharedDependencies into GenerateAndroidBuildActions
Support AllowMissingDependencies in prebuilt_apex modules
Support AllowMissingDependencies for apex dependencies
Add AllowMissingDependencies support for prebuilt_etc module with no src property
Make OutputFileForModule work for AllowMissingDependencies
Fix panics when target arch is riscv64
Apexes for new architectures have to increase their minSdkVersion
to the minimum supported version for the architecture.
Bug: 250918230
Test: lunch aosp_riscv64-userdebug && m ALLOW_MISSING_DEPENDENCIES=true nothing
Change-Id: I49220cbec628f1508709741dc56b62aaac7786d9
Make rust and cc fuzzers collect their shared libraries once in
GenerateAndroidBuildActions and store it for later use by the
packaging singleton. Also use android.OutputFileForModule to get
the paths. Together this will fix fuzzers that depend on architecture
specific prebuilt shared libraries that are missing a prebuilt for an
architecture when building with AllowMissingDependencies.
Bug: 250918230
Test: lunch aosp_riscv64-userdebug && m ALLOW_MISSING_DEPENDENCIES=true nothing
Change-Id: I154a6f3a767c883e9fe7067003615db73ee78e2d
Currently, tagging a symbol with #apex is not required when the symbol
is in a non-NDK library. However, this is considered dangerous because
such a symbol will automatically be promoted to NDK APIs when the
library is promoted to an NDK library. When that happens, the native API
council won't be able to notice the promotion because promoting a
non-NDK library into an NDK library doesn't require an update of the
map.txt file, but Android.bp only.
To prevent that, we should mandate #apex (or #systemapi if the api is
provided by the system, not apex) tag for Mainline APIs regardless of
whether the library the API belongs to is an NDK library or not.
Bug: 184712170
Test: m
Change-Id: Iad589b606bc6ed06ef1237f4c9f0c22518b0db75
By default, ndkstubgen does not omit NDK symbols as long as they
satisfy the API version and the CPU architecture requirements. This
change adds a new flag --no-ndk to ndkstubgen which is used to
override the default behavior. If the flag is set, NDK symbols are
omitted leaving only the annotated symbols (e.g. #apex, #systemapi,
etc.).
This will be used for stub libraries that are not part of NDK. So far,
symbols in such libraries haven't needed to be annotated as #apex, and
that has caused a confusion that those symbols belong to NDK. The
follow-up change will ensure that those symbols are always annoated as
either #apex or #systemapi so that their roles are clearly visible.
Bug: 184712170
Test: atest test_ndkstubgen
Test: atest test_symbolfile
Change-Id: Ic8d2c7d0b32bdef79f7563621035e60f406e4131
* This is a temporary work around until the RBE input processor
can handle those flags.
* It's okay to remove some cflags in clang-tidy command
if they do not affect tidy check results.
Bug: 248371171
Test: enable RBE; RBE_CLANG_TIDY_EXEC_STRATEGY=remote; make tidy-soong_subset
Change-Id: If499bd7e1f0f89ccc3b7f7df7d67cfc64dc67028
