Bug: http://b/137883967
With coverage enabled, native-bridge modules throw a SEGV_ACCERR.
Test: Successfully run the app linked in the bug on a coverage build.
Change-Id: I9f3622b7b6d3189337c445a26d6bf81c96820c2e
Ensure that it ends up in the bionic/ subdir in the Runtime APEX and is
symlinked from /system/lib(64). That makes it available in the default
(platform) linker namespace and no longer requires it to be accessible
through the runtime namespace. All this makes it consistent with how the
other Bionic libs are handled, and avoids the need for various special
cases in ld.config.txt files (to be cleaned up later).
With this there might no longer be a need for a linker namespace for the
Runtime APEX, and we could consider removing the kludge with the
/apex/com.android.runtime/${LIB}/bionic subdirectories and the special case
in getCopyManifestForNativeLibrary in apex.go. However, keeping it calls out
the special treatment of those libraries, and allows a namespace to be added
again if necessary.
Test: Build and boot on taimen_hwasan-userdebug
Test: adb shell /apex/com.android.art/bin/dexdump on taimen_hwasan-userdebug
Test: atest CtsCompilationTestCases on taimen_hwasan-userdebug
Bug: 140734238
Bug: 140790209
Change-Id: Ieb506bfa5d5c159db391273c7eba41d7909de286
"apex_vndk" is a variant of "apex" module.
apex_vndk {
name: "com.android.vndk",
..
}
This rule is used to produce a VNDK APEX per vndk version.
It supports automatic inclusion of vndk libs.
If "vndk_version" property is set, the prebuilt vndk libs of
the version will be included in the apex bundle.
apex_vndk {
name: "com.android.vndk.v29"
vndk_version: "29",
...
}
Otherwise, platform's vndk version is used.
This will replace /system/{lib}/vndk-{ver} and vndk-sp-{ver}.
Bug: 134357236
Bug: 139772411
Test: m com.android.vndk
Change-Id: Ib5c86e625839389670d13c683a7427198ef6852f
native_bridge modules may not have vendor variants because they are
used only for native_loader.
Bug: 140702618
Bug: 137709824
Test: lunch aosp_cf_x86_phone-userdebug && make
Change-Id: Ic9f4abff22597693e66eef520cd1101b5e8c8938
Adds support to Soong for building rust modules. This currently only
supports x86_64 device and x86 linux host targets. The functionality
is sufficient to build crosvm.
Bug: 136189233
Test: Test module builds.
Test: crosvm builds.
Change-Id: I6ea04615834a6d673578ab10ea1a2eb04259fe09
Usually, ".S" files are processes with the c preprocessor, and ".s"
files are not, so they don't have any dependency information, since it
is generated by the preprocessor.
But with the -xassembler-with-cpp flag, ".s" files are processed with
the preprocessor, so we should ask for dependency information from them.
Test: NINJA_ARGS="-t deps out/soong/.intermediates/external/sonivox/arm-wt-22k/libsonivox/android_arm_armv7-a-neon_core_static/obj/external/sonivox/arm-wt-22k/lib_src/ARM-E_filter_gnu.o" m
Test: treehugger
Change-Id: Iee7baeebc2b205b5a2f33e7c1705ea4a5b4fc95a
* changes:
Introduce inject_bssl_hash library property.
BoringSSL FIPS build - introduce extraLibFlags and use for STL libs.
Allow linker scripts when building objects.
Allow .o files as srcs.
Rationale: On non-bionic, stl.go currently adds system libraries to
ldFlags, this causes problems for partialLd rules. However adding the
same libraries to libFlags breaks some existing modules due to symbol
conflicts as the system libraries are linked before some module code.
Introduced a general mechanism for adding libraries to be linked
last rather than making this STL-specific.
Bug: 134581881
Bug: 137267623
Test: TH
Change-Id: I779f28c6586b3fea85cc6299b686e4fde95262d3
When the native coverage is enabled, APEXes (and files there) are built
for native coverage as well.
Bug: 138952487
Test: make -j NATIVE_COVERAGE=true COVERAGE_PATHS='*' com.android.resolv
find out -name "*.gcno" | grep DnsResolver shows files
Test: libnetd_resolv.zip is found under
$(TARGET_OUT)/apex/com.android.resolv/lib directory
Change-Id: I97bcee9bf8ffc0dc71453abbdb613ed56ea2cdb4
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
When no-vendor-variant VNDK is enabled,the vendor variant of VNDK
libraries are not installed.This should not be fit for recovery module.
Recovery module deps should be always installed.
Bug: 138812833
Test: `adb reboot recovery;` recovery mode boot ok
Change-Id: I0c3b8ac0fb0176677ddd94ba7216dd068f2eb81b
In `apex.apexBundle.GenerateAndroidBuildActions`, we used to pass the
"all tests" ("") module as `module` for all `apexFile` objects created
from a test module using `test_per_src: true`. An immediate issue of
this situation was that the "" module is hidden from Make, which made
all the generated `apexFile` objects hidden from Make too. This would
break the construction of flattened APEXes, as they rely on Make logic
to install their files.
Instead of collecting `test_per_src` test variations' output files in
`cc.Module.GenerateAndroidBuildActions` and using them in
`apex.apexBundle.GenerateAndroidBuildActions` as part of handling the
"" variation as a direct dependency of an `apexBundle`, process them
as indirect dependencies (and do nothing for the "" variation direct
dependency).
Adjust the indirect dependency logic in
`apex.apexBundle.GenerateAndroidBuildActions` to allow not only
shared/runtime native libraries as indirect dependencies of an
`apexBundle`, but also `test_per_src` tests.
Test: m (`apex/apex_test.go` amended)
Bug: 129534335
Change-Id: I845e0f0dd3a98d61d0b7118c5eaf61f3e5335724
Use Kythe (https://kythe.io) to build cross reference for the Android
source code. ~generate the input for it during the build. This is done
on demand: if XREF_CORPUS environment variable is set, build emits a
Ninja rule to generate Kythe input for each compilation rule. It
also emits two consolidation rules (`xref_cxx` and `xref_java`),
that depend on all Kythe input generation rules for C++ and Java.
The value of the XREF_CORPUS environment variable is recorded in the
generated files and thus passed to Kythe. For the AOSP master branch it is
`android.googlesource.com/platform/superproject`, so the command to build
all input for Kythe on that branch is:
```
XREF_CORPUS=android.googlesource.com/platform/superproject m xref_cxx xref_java
```
Each Kythe input generation rule generates a single file with .kzip
extension. Individual .kzip files have a lot of common information, so
there will be a post-build consolidation step run to combine them.
The consolidated .kzip file is then passed to Kythe backend.
The tools to generate .kzip files are provided by Kythe (it calls them
'extractors'). We are going to build them in toolbuilding branches
(clang-tools and build-tools) and check them in as binaries into master
and other PDK branches:
For C++, `prebuilts/clang-tools/linux-x86/bin/cxx_extractor`
for Java, `prebuilts/build-tools/common/framework/javac_extractor.jar`
Bug: 121267023
Test: 1) When XREF_CORPUS is set, build generates Ninja rules to create
.kzip files; 2) When XREF_CORPUS is set, building
`xref_cxx`/`xref_java` creates .kzip files; 3) Unless XREF_CORPUS is
set, build generates the same Ninja rules as before
Change-Id: If957b35d7abc82dbfbb3665980e7c34afe7c789e
If a test module with a `test_per_src` property set to `true` is
included in an APEX module, add all the variants for mutator
`test_per_src` as dependencies of the APEX module (not just the
first one).
This is done by adding variation "" of mutator `test_per_src` when
adding a test dependency to an APEX module, which creates an indirect
dependency of the APEX module on all the `test_per_src` variants of
the test module. When generating outputs for the APEX bundle, fetch
and include the set of test outputs from the "" variant.
Test: m (`apex/apex_test.go` amended)
Bug: 129534335
Change-Id: I1c99855971a8a9b2fc5b964a420e882b6791d4e6
Have `cc.testPerSrcMutator` create an additional variation named "",
having no sources (and generating no output file), but depending on
all other `test_per_src` variations and collecting their output files
in a new field named `cc.Module.testPerSrcOutputFiles`. This is useful
in the case where a module depends on all the `test_per_src`
variations of a test module.
Test: m
Bug: 129534335
Change-Id: I905decc0b9417f47cee9113466677d3bb61ad7b6
Needed to allow removal of the include_dirs property from the
asm_defines.s module. Also, adds ObjectLinkerProperties to cc_defaults
so that default settings of header_libs are correctly prepended to the
properties in cc_object.
Bug: 35624006
Test: m cpp-define-generator-asm-support - compare output before and after change
Change-Id: Ib95d79c5eba4a89b7ab04b6c62090b720ec7e9fe
Bug: http://b/134177005
Bug: http://b/116873221
Previously, the libprofile-extras dependency was added as a
LateStaticLib and the constructor in this library was included during
linking with the '-uinit_profile_extras' linker flag. This was done
because at the deps() stage, the exact binaries that need coverage are
not known (in fact the coverage-enabled variants are not created yet).
This meant that for a link command, if one of the shared libraries
already exported the constructor, the output of the link command did not
load/link libprofile-extras.
For other reasons, we now want to add more symbols to this library that
need to be linked into all libraries and executables. To accomplish
that, refactor the dependency handling so libprofile-extras can be added
as a 'WholeStaticLib'.
This is done by creating a new dependency type (with a coverageDepTag
dependency tag) to add libprofile-extras as a dependency for all modules
that can potentially link with coverage. During the flags() call, this
dependency is moved as a WholeStaticLib dependency iff coverage is
enabled in this link step.
There are a few NFC changes as well:
- deps() takes a DepsContext parameter.
- flags() has an extra PathDeps parameter and return value.
- add useSdk() helper to cc.Module.
Test: Build with coverage and check that we can generate coverage using
SIGUSR1 and the debug.coverage.flush sysprop.
Change-Id: I7e7d8201956a150febbda5bb1794f8ece016db8b
This commit enables ABI diff for libraries without source.
Stub libraries are excluded.
Test: ./create_reference_dumps.py -products aosp_arm64
Test: make
Bug: 135728451
Change-Id: Idbe276db6f5e057175fc098f0226cb38996faa17
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
* changes:
Consolidate *MutatorContext and ModuleContext into BaseModuleContext
Add test for missing defaults modules with AllowMissingDependencies
Capture missing dependency error rules
Share buildDir for android/soong/android tests
Reimplement AddMissingDependencies
Add GenerateAndroidBuildActions to DefaultsModuleBase
Exported includes have been maintained along with other C/C++ flags.
This makes dependencies unclear, and users have had to parse flags to
get exported directories. This separates exported includes and
exported flags, thus making data more structured and explicit.
Bug: 132818174
Test: m
Change-Id: I5c25ac2224988c4a67e4db6fd6e4d39090b74041
Add an empty GenerateAndroidBuildActiosn to DefaultsModuleBase
so that every defaults module doesn't need to provide one. This
will also allow adding an implementation in the next patch.
Test: m checkbuild
Change-Id: I13554bdb3a287c2f18e1efab74d4f08a1ba8620c
blueprint.BaseModuleContext is the set of methods available to all
module-specific calls (GenerateBuildActions or mutators). The
android package split the same functionality across baseContext (nee
androidBaseContext), BaseModuleContext, and BaseContext.
Consolidate all of them into android.BaseModuleContext.
Test: m checkbuild
Change-Id: I2d7f5c56fd4424032cb93edff6dc730ff33e4f1e
There are cases where a module needs to refer to an intermediate
output of another module instead of its final output. For example,
a module may want to use the .jar containing .class files from
another module whose final output is a .jar containing classes.dex
files. Support a new ":module{.tag}" format in any property that
is annotated with `android:"path"`, which will query the target
module for its ".tag" output(s).
Test: path_properties_test.go, paths_test.go
Test: no unexpected changes in build.ninja
Change-Id: Icd3c9b0d83ff125771767c04046fcffb9fc3f65a
- 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
This fixes the problem with cc_object not having this suffix and
as a result overriding non-bridged variants for modules using mk files.
Bug: http://b/77159578
Test: build 4arch product
Change-Id: Ie958f997c6f54f93d8b2987ca5ba605004e1eb70
Do not rely on 'module.Name()' to decide VNDK link type.
Some prebuilt modules such as libclang_rt_prebuilt_library_shared and
vndk_prebuilt may have different naming schemes.(prefix/suffix)
And llndk_library module has '.llndk' suffix.
Instead, use VNDK-related properties (e.g. vndk.enabled,
vendor_available, etc.).
Bug: 132800095
Test: m & check LOCAL_SOONG_LINK_TYPE for prebuilts
Change-Id: I06b0c182aeab16969c44a86397f02be4beb80bbd
For vndk_prebuilt_shared module, it is set by 'version' property.
For other vndk libs(e.g. cc_library with vndk.enabled), it is set as
PLATFORM_VNDK_VERSION.
Background:
To support "skip installing current VNDK".
You can get a system.img without current VNDK libs.
This may help when you want a smaller system.img given that the image
will be used with a specific version (not current) of vendor image.
Bug: 132140714
Test: m TARGET_SKIP_CURRENT_VNDK=true && see if current VNDK is not
installed
Change-Id: I1c603efc3e95fe8bdf870f2de91994077899fca7
When HWASAN is enabled, the runtime is conceptually part of Bionic (and
mutually depends on it), so it needs to be treated in the same way as the
Bionic libs.
Now there are only two copies of the runtime: the one in
/system/lib64/bootstrap (which won't be used by ordinary processes) and the
one in the runtime APEX.
This reduces the size of the HWASAN system image and fixes an issue where
multiple copies of the HWASAN runtime were being loaded into 64-bit binaries in
APEXes because the linker namespace for the binary is different from the one
for its dependent libraries outside of APEXes. HWASAN only supports loading
one copy of the runtime per process, so this was causing such binaries to
crash on startup.
Change-Id: I228896e193a035e6dfba9f6e28d0b2e12fc163ea
This is the first commit to generate VNDK snapshot with Soong: .so
files, some txt files, and notice files are captured with Soong. As
ld.config.txt is currently in Android.mk and will be deprecated soon,
configs files (and zipping all of artifacts) are still handled with
Makefile.
Bug: 131564934
Test: 1) DIST_DIR=out/dist development/vndk/snapshot/build.sh
Test: 2) try installing vndk snapshot with:
development/vndk/snapshot/update.py
Change-Id: I8629e1e25bfc461fd495565bb4872c9af176cf92
This allows us to build guest libraries for the native bridge for
arm/arm64 architectures.
Bug: http://b/77159578
Test: make
Change-Id: I35520ca456105ddadd456c78a4eb1e6de39147c5
This commit allows a module to opt in for ABI checks even when it is
not an LLNDK/VNDK module.
Bug: 131421213
Test: Add `header_abi_checker { enabled: true, }` to some module
Change-Id: Ie09d262e651cbb44d7d0eba652f55dc1e1e52962
So that <module>/gen/yacc/... is (re)created by a single rule, previous
files are removed, and location.hh is in the build graph when it is
produced.
Test: treehugger
Change-Id: I2f6e47ea07f315e10ae1cb8ad50697e7123d0285
Add a proto.plugin property to allow specifying a custom protoc
plugin to generate the code.
Fixes: 70706119
Test: m am StreamingProtoTest
Change-Id: I1ecdd346284b42bbcc8297019d98d2cd564eb94c
Using blueprint.Rule for protoc commands was causing code duplication
because there was no good way to run the same protoc for cc, java and
python but then run custom source packaging steps for java and python.
Move most of the code into a common function that returns a
RuleBuilder, and then let java and python add their own commands at
the end of the rule.
Bug: 70706119
Test: All Soong tests
Test: m checkbuild
Change-Id: Ic692136775d273bcc4f4de99620ab4878667c83a
Bug: http://b/128524141
Include libprofile-extras (defined in system/extras/toolchain-extras) to
all modules that need a coverage variant. Also add
'-uinit_profile_extras' when linking with coverage. This causes the
setup code in libprofile-extras to be linked into binaries/libraries
with coverage enabled.
We add the static library to the non-coverage variants as well but is a
no-op for them (since the '-u...' flag is not added for them).
Adding this dependency creates several circular dependencies since
coverage variants were being created for other module types that never
had any compilation or linking done during the build. This change stops
creating coverage variants for toolchain_library, cc_prebuilt_library_*,
cc_library_headers module types (by adding a function to the linker
interface to specify whether native coverage is enabled).
Test: m NATIVE_COVERAGE=true COVERAGE_PATHS=*
Test: blueline_coverage target in internal branch (using forrest)
Change-Id: I5db876eb953639a55ba007248dd24e497f987730
