We add an optional Symbol_ordering_file property to linker properties
to allow modules to specify the order of symbols in the binary.
Bug: 112073665
Test: Build libc with a symbol ordering file and check the resulting
binary.
Change-Id: Ibb24697cfdee4a5750442cb74f1ee6390d8a6430
Stubs libs are built with the generated version script file.
Bug: 120266448 (comment #23)
Test: lunch walleye_hwasan-userdebug
make SANITIZE_TARGET=hwaddress oatdump
Change-Id: I38652e61d0b336227b7f541590b0e70fe291f0a3
This change first introduces the interface "Sanitizeable" that
module types other than cc.Module can use to be handled by the sanitizer
mutator. APEX module, by implementing the interface, gets sanitizer
variants.
In doing so, sanitizer.go is refactored so that modules have explicit
dependencies to the runtime sanitizer libraries. This allows the runtime
library to be packaged into the APEX when required. This also completes
the dependency graph; updating the prebuilt sanitizer runtime will
trigger rebuilding of modules using the runtime.
Bug: 120894259
Bug: 121038155
Test: SANITIZE_TARGET=hwaddress m apex.test
Test: TARGET_FLATTEN_APEX=true SANITIZE_TARGET=address m
Change-Id: Ia91576ff48cda3c996350308b75bf83fcf7c23d7
This reverts commit 769e50b3c9.
Reason for revert: Likely causing build failure on aosp_x86_64-eng in aosp_master:
"build/make/core/base_rules.mk:271: error: art/build/apex: MODULE.TARGET.SHARED_LIBRARIES.com.android.runtime.host.libart-compiler already defined by art/build/apex."
Change-Id: I83b7caa04b2648e4e4914aae2fa5878516634eed
This cherry-pick update picks up a few patches to improve hwasan, ELF
tls, and LLD for kernel builds.
Bug: http://b/122549771
Test: make checkbuild, boot
Change-Id: I8a90282af41ad4c74df819484ba2c3507e20100f
The unstripped file for libraries in APEXes are available via
out/target/product/<device>/symbols/apex/<apex_name>/path_to_lib.
This change make the symbol files available by installing the individual
files in APEXes to the directory where the APEXes will be mounted at
(i.e. runtime directory which is /apex/<apex_name>). Note that the files
are not actually packaged to a filesystem image; they are installed just
to create the symbol files under the out directory where developers can
use them for debugging.
Bug: 120846816
Test: m com.android.runtime.debug
There are unstripped files under
out/target/product/walleye/symbols/apex/com.android.runtime.debug
Change-Id: Ib182e2bf8787b7669ccba13814491db35370f468
If a lib is directly included in an APEX (via native_shared_libs
property) and the lib has stubs (via stubs.versions property), then the
ordinary non-stubs variant of the library is renamed to
<libname>.bootstrap in the makefile. At the same time, the stubs variant
of the lib becomes visible and it's name is <libname>.
This ensures that modules in Android.mk build against the stubs
variant thus preventing them from using private APIs in the lib.
The non-stubs variant, however, is used if the module explicitly has
set the new 'bootstrap' property to true. This is useful for building
some early binaries (such as init and vold) which need to run before
APEXes are activated. Since they can't use the bionic libs from the
runtime APEX, they should use the bionic libs left in the system
partition which is called the boostrap bionic.
Bug: 120266448
Test: m
Test: m with https://android-review.googlesource.com/c/platform/bionic/+/849044
Change-Id: I882b8aeb5b29460f07b4424e4f8eb844d6c9a9b0
.s files (unlike .S files) aren't run through the preprocessor, so -M*
doesn't actually write out a depfile.
Since our ninja is now going to be verifying that the depfile is created
(https://android-review.googlesource.com/861510), don't specify a
depfile for .s files.
Bug: 121058584
Test: apply https://android-review.googlesource.com/861510
Test: cd external/libavc; mma
Change-Id: I1697aa020c63639317c8f4771147026601ae72fc
This commit stops building lsdump files for APEX variants since APEX
variants are local to APEX modules themselves.
Bug: 121986692
Test: make findlsdumps # compare $ANDROID_PRODUCT_OUT/lsdump_paths.txt
Change-Id: I37fcd152d0d84d235a354ea53e53e808dd71464a
This CL fixes the problem that when a lib is defined with stubs, the
stubs variantof the lib is installed to the APEX. This was happening
because the non-stubs variant is the last variant of the 'version'
variants and addFarVariationDependencies selects the first variant when
the 'version' variant isn't specified.
Fixing the problem by making the non-stubs variant (whose name is "")
the first variant.
Test: m (apex_test)
Change-Id: I1505fd2f29a0d70c916bad51000aa06f2b80b137
This change fixes a bug that the 'required' property of a module is
ignored when the module is using a shared from an APEX. This is
happening because LOCAL_REQUIRED_MODULES is overwritten (with := instead
of +=) when ApexesProvidingSharedLibs is not empty.
Fixing the bug by appending ApexesProvidingSharedLibs to
AndroidMkData.Reuired so that it is handled in android/androidmk.go
Test: m
Test: build with https://android-review.googlesource.com/c/platform/bionic/+/849044
and make sure that system/bin/vold_prepare_subdirs exist.
Change-Id: Ie57bca480ba4198b4da0df1c73e92fa42b5ebda8
This change fixes following problem:
1) a native lib having stubs is defined.
2) the lib is included in an APEX.
3) a static binary is linking the lib from outside of the APEX.
4) then, the dependency from the binary to the lib is vanishing.
This is happening because cc.depsToPaths() mistakely does not
distinguish static lib deps from shared lib deps. For shared lib deps,
it creates two dependencies (one for stubs variant and the other for
non-stubs variant) and choose the stubs variant when the lib and the
current module is not in the same APEX (i.e. dependency to the non-stubs
variant is discarded). However, since we don't have stubs variant for
static library, it ends up having no dependency to the library if the
link is static.
Fixing the issue by skipping the variant selection routine when the link
is static.
Test: m (apex_test added)
Test: build with https://android-review.googlesource.com/c/platform/bionic/+/849044
Change-Id: I21102a31cc5c0b105da2affdd035bd5cc571a6ab
use_vendor, when set to true, brings vendor variant of the native
libraries and binaries to the APEX.
Bug: 115707625
Test: m (apex_test updated)
Change-Id: Ib4e996f8652f4ce4645a9c22f6914e2ab35edda6
The dependency is added because the module that uses the sysprop library
needs generated code before it is built.
Test: m -j
Change-Id: I2858fc6fa6f2fe16afa2f4a7ae62746ba0f67e5c
Ie42edc5184f315f998db953594e425214b810e0e added system_shared_libs to
static libraries so that their exported headers can be referenced.
However, it also added unrequired dependencies, which is an
error-triggering issue for static executables.
This change addresses it by adding a condition to shared libs handling code
in binary.go.
Bug: 121152570
Test: cc_test.go, library_test.go
Change-Id: I1828442c4e496f8d815fccaeca970cd5766bdf5d
Now, symbols that are only to be visible to across APEXes can be tagged
as # vndk. Then when generating the stubs library, the tagged symbol
is included. The symbol is NOT included in other cases; build NDK stubs,
etc.
Bug: 120638081
Test: m (apex_test updated.)
Change-Id: Idb2b552badddfc26af113cc8d4b984788f478813
If a symbol is tagged as # apex, then it is exported when gen_stub_libs
is invoked with --apex.
Bug: 120638081
Test: python3 cc/test_gen_stub_libs.py
Change-Id: I190bca35d1a4fb422b37d1be41a34de1ad64de6b
Otherwise, the force included headers might cause conflicting types
error with the symbols in the generated stubs source code. e.g.
double acos(double); // in header
void acos() {} // in the generated source code
Bug: 120266448
Test: m (apex_test also updated, and passing)
Change-Id: I717df990959d1b24ec515f0f52a4e28b94e92f32
The runtime APEX is built for host as well as for target. Therefore
stubs libs should be available also for host.
Bug: 120670568
Test: follow the repro step shown in b/120670568#comment4
Change-Id: I350fe490848ae9ceb55aade0521bdfaf48ed083f
This change fixes a problem that APEX variations are created for the
modules that actually shouldn't built for any APEX. For example,
consider this case.
apex { name: "myapex", native_shared_libs: ["mylib"],}
cc_library { name: "mylib", shared_libs: ["libfoo#10"],}
cc_library { name: "libfoo",
shared_libs: ["libbar"],
stubs: { versions: ["10"], }, }
cc_library { name: "libbar", ...}
Before this change, both the stubs and non-stubs variations of libfoo
were mutated with apexMuator, which is incorrect for the non-stubs
varia; there is no dependency chain from the apex "myapex" to the
non-stubs variation, but to the stubs variation due to the #10 syntax.
This was happening becauses we used the name of the module to determine
whether it should be built for APEX or not. Both stubs and non-stubs
variations have the same module name "libfoo".
Fixing this issue by recording the list of APEX variations required
directly on the module. So, the stubs variation of libfoo has myapex in
its apex variations list, but the non-stubs variation doesn't, and thus
apexMutator does not pick up the non-stubs variation.
Test: m (apex_test updated and passing)
Test: cherry-pick ag/5747464 and m
Change-Id: I31e618626809a828a55fff513ef5f81f79637afa
When the stubs variant of a library is dependend by a platform component
and the library is included in one or more APEX, the library is not
installed to the platform, because it is provided by APEX.
Bug: 120266448
Test: m
Test: add stubs: { versions: ["1"], }, to libnetd_resolv
then build netd. libnetd_resolv.so does not exist under /system.
Change-Id: I09b78e38df285033ef6e9c85f7ea4b0274e85070
Add a no_recover option that allows specifying which sanitizers in
diagnostics modes shouldn't recover. This can help debugging as we test
enabling sanitizers in new libraries since it'll cause tombstones to be
generated along with the diagnostics information.
Bug: 80195448
Bug: 110791537
Test: Compiled test module with this flag, checked compiler command.
Test: Test module crashed, tombstone contained diagnostics information.
Change-Id: Ie938923ef95716c2d49d6cd719ee223ad62755c6
Stubs libs are build-time only artifact. Can't be installed.
Test: OUT_DIR=out build/soong/scripts/build-ndk-prebuilts.sh
with https://android-review.googlesource.com/c/platform/frameworks/av/+/846770/7
and two more CLs in the same chain
Examine out/soong/build.ninja
Build rule for out/soong/target/product/generic_arm64/system/lib64/arm64/libmediandk.so
exist only once.
Change-Id: I58ff09ef3fbbdbd2d968aa21b87a493192d4216d
Stubs libs are not built with dependencies required for cfi and stl.
Also it does not make much sense to build stubs with cfi and stl because
the libs are not for runtime and there is no C++ symbols.
Test: cherry-pick ag/5747464 and m
Change-Id: I83d6d82513a77a6a8a345e7d12707940c2c906c7
