crt_pad_segment adds a NOTE to the ELF which is used by the binoic
loader to determine whether it should pad segments when mapping them
into the virtual address space, such that there are no gaps between
mappings of consecutive segments. This avoids an increase in
unreclaimable kernel slab memory usage for VMAs on devices where the
runtime-page-size > elf-segment-p_align.
Since -fandroid-pad-segment [1] respects -nostdlib used in android
platform builds, soong must link in crt_pad_segment to platform shared
libraries.
For simplicity, link crt_pad_segment everywhere that crtend_so is
applicable, ignoring nocrt property, as there is no other reason
to track these separately.
Example:
❯ readelf -WS /system/lib64/libc++.so [Output simplified]
...
Section Headers:
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
...
[ 2] .note.android.pad_segment NOTE 0000000000000288 000288 000018 00 A 0 0 4
...
[1] https://github.com/llvm/llvm-project/pull/77244
Bug: 316403210
Test: readelf -WS <lib>.so
Change-Id: Icc06611376cfd5ee4de7281b4134f9f8ffe7ca60
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Current VNDK prebuilts are disabled if BOARD_VNDK_VERSION is not set,
but VNDK prebuilts should be enabled even BOARD_VNDK_VERSION is not set
because VNDK APEXes should be available from VNDK deprecation. This
change removes some restrictions on VNDK prebuilts to enable those from
VNDK deprecation.
Bug: 316829758
Test: AOSP Cuttlefish build succeeded without BOARD_VNDK_VERSION
Change-Id: Id780811dab26f2125097c3efc5b2b4a59416b826
LLNDK will not be finalized at the same time with NDK and APEX
libraries. The ABI dumps need to be generated and stored separately.
In lsdump_paths.txt, each dump path is tagged with LLNDK, NDK, etc. A
library may have multiple dumps with different tags. The finalization
scripts will read lsdump_paths.txt and select the dumps for LLNDK.
LLNDK versioning for trunk stable has not been implemented. Currently
the dumps for LLNDK, APEX, NDK are identical.
Bug: 314010764
Test: make out/target/product/generic_x86_64/lsdump_paths.txt
Change-Id: Ia8eed555dc176b221e67b3b049dd3db76f9bc658
Some clang unused-* warnings are not covered by "-Wno-unused". Add them
explicitly to avoid noise from these warnings, given that they don't
generally get fixed.
Test: Local clean builds.
Change-Id: I13f5089fd68f1a67a11be14fa41807688d803ba3
Similar with aosp/2897612, rename LOCAL_USE_VNDK into
LOCAL_IN_VENDOR or LOCAL_IN_PRODUCT to make variable useful from
VNDK deprecation.
Bug: 316829758
Test: AOSP CF build succeeded
Change-Id: I76741e45a2d80000adec6abfd8e9d6ee97c4ea23
LLNDK will not be finalized at the same time as APEX and NDK. The
dumps have to be placed in a different directory. The new LLNDK dumps
will be created in "vndk" directory.
Test: lunch aosp_x86_64-next-eng ; make
Bug: 314010764
Change-Id: I0726e3eabcfdbfb94a10f01ddd6dfb971552bd50
This CL is scoped to cc_* module types. With trunk stable, we will have
multiple prebuilts of the cc modules in
prebuilts/module_sdk/art/<v>/host-exports/, and this CL introduces a
mechanism to use apex_contributions to select a specific versioned
prebuilt when building.
If a soong module is selected using apex_contributions, all rdeps will
get that soong module, which includes
- rdep soong modules which might be depending on it via Android.bp
- Soong's rule builder HostToolPath API
Implementation details: Create a new source_module_name property to
identify the root module. rdeps referring to the root module will get
redirected if necessary. This property also
becomes the stem, if `stem` is not set explicitly.
Bug: 322175508
Test: Added a unit test
Change-Id: Ic8725602c81999621fcb33ce2a57fe4b9751baa8
Add the dependency on the fdo_profile module in afdoTransitionMutator
and read the provider in GenerateAndroidBuildActions.
Bug: 319288033
Test: afdo_test.go
Change-Id: Ied8fd7b52d5694a3691652318e87b8fe14dda126
Convert afdoDepsMutator and afdoMutator to a TransitionMutator as a
step towards variants-on-demand.
Bug: 319288033
Test: afdo_test.go
Change-Id: Ib05845455ccf43a07b3915a0d7b0a95896062f13
Convert orderfileDepsMutator and orderfileMutator to a TransitionMutator
as a step towards variants-on-demand.
Bug: 319288033
Test: orderfile_test.go
Change-Id: I27df65b7264a5b059a900e7ea04c18dfb2787a84
Convert ltoDepsMutator and ltoMutator to a TransitionMutator as a
step towards variants-on-demand.
Bug: 319288033
Test: lto_test.go
Change-Id: I2c9af73fd526adf58ff626831ababea466338205
Convert coverageMutator to a TransitionMutator as a step towards
variants-on-demand.
Bug: 319288033
Test: coverage_test.go
Test: treehugger coverage builds
Change-Id: Ic50c0040dea8b42c36b5d784221daa00b7b0d379
For chromebooks, we need a new build variant whose target arch is
goldmont, but without SHA and XSAVES support (b/314243939#comment21)
Bug: 314243939
Test: Build an image with TARGET_ARCH_VARIANT:=goldmont-without-sha-xsaves
Change-Id: If73660b515b443d5c138ca367fa3d1c6f18485b5
Although vendor modules can be built bundled, they are technially not
part of the "platform", as it cannot access platform libraries (system
partition) directly.
They can only link to a restricted set of platform libraries (LLNDK),
and access restricted set of APIs.
We used to derive the LLNDK API level from the VNDK version. However
after VNDK deprecation, there is no "VNDK version" anymore.
Instead we would just derive the value from platform SDK version:
* If building an in-development build, build vendor modules against the
in-development "current" API level.
* If building a REL / Final build, vendor should target the latest
stable API.
Bug: 320423828
Test: go test
Test: presubmit
Test: build and boot
Change-Id: I2c5ef6530e9046b2dcc282bc1f020d8a505eab15
No-one ever fixes unused-* or deprecated-* warnings in external/ (nor should they!).
-Wno-deprecated-enum-enum-conversion should probably have been added
next to -Wno-deprecated-anon-enum-enum-conversion when it was added,
since it's a major spam contributor, and equally unlikely that anyone
will clean them up.
-Wno-deprecated-dynamic-exception-spec is a weird special case because
it should be irrelevant after our next libc++ update, but in the
meantime -- because libc++ is used everywhere -- this is a massive spam
contributor that no-one on Android cares about because we don't use
exceptions (and the people seeing this can't fix libc++ anyway).
Test: local clean builds
Change-Id: I098202337e9e5026c4c5215dbf5a2abf1fbbdca8
The previous patch was insufficient. Craig Topper explains:
-fno-vectorize only disables the loop vectorizer
-fno-slp-vectorize only disables the SLP vectorizer
The backend can also use vector instructions for memcpy/memset or
combining multiple scalar loads and/or stores. That is independent
of -fno-vectorize.
-mllvm -vector-bits-min=0 will disable any use of fixed vectors. And
will make attribute(vector_size) get scalarized.
-mno-implicit-float will disable both vectorizers and
prevent the backend for using vectors for memcpy/memset
oor multiple scalar loads/stores. It will not affect
attribute(vector_size). -mno-implicit-float also prevents scalar
floating point instructions from being used for anything that didn’t
use float/double/_Float16/etc. type in source, but I don’t think that
happens on RISC-V today. 32-bit X86 can use a 64-bit x87 FP load as an
atomic load for uint64_t, for example. Basically -mno-implicit-float
is supposed to prevent the compiler from using FP or vectors when the
source doesn’t explicitly use FP or vectors.
So -mno-implicit-float was what we were actually looking for here. I've
done a clean build with this change, and see only the expected
(hand-written assembler) vector code in bionic, and the ART
ClassLinker::LoadClass() issue is gone too. As far as I can tell, the
remaining vector code is all deliberate in that sense.
We may still end up back here again, to change "gcv" to "gc", but that
still requires some code changes just to build, and still makes it less
obvious that this is just a temporary workaround for a qemu bug
(specifically https://gitlab.com/qemu-project/qemu/-/issues/1976).
Bug: http://b/320416684
Test: objdump
Change-Id: Ibd104e4289d6d1aaf441efa0440fedc90e3da29a
* changes:
Add script to run Soong tests with go tools
Disable TestVariantSingletonModule when go test -short is used
Fix data race in propagateRROEnforcementMutator
Fix data race in finder_test.go
Fix data race in dex_bootjars
Fix race CommonGlobalCflags when running tests in parallel.
Fix data race in snapshot singletons when running parallel tests
Until https://gitlab.com/qemu-project/qemu/-/issues/1976 is fixed, this
is just causing too much confusion and wasted time.
Removing V from the architecture string has the same effect, but
requires some code changes (to be able to compile code that's
_explicitly_ using V), and makes it less obvious that this is just a
temporary workaround for a qemu bug.
Bug: http://b/320416684
Test: objdump
Change-Id: Iec7d63ab227b31f82f530dabbdc4f3aa54277f04
Clone the commonGlobalCflags global variable when modifying it so that
it gets a unique object per context.
Test: go test -race ./...
Change-Id: Ia4b91c40939d4b4d338bd11e4d4f523521874548
This change is to fix more misc issues to enable Soong without VNDK
version. This change contains
* Update properties in generated Android.mk
* Update VNDK APEX build to work without VNDK version
Bug: 316829758
Test: AOSP Cuttlefish build succeeded
Change-Id: I10f3c798299afe2d539ec3426b8e2b6068a158f6
Generated codes like cpp code from *.ll for *.yy files always run
clang-tidy, when generated code has warning, where is no way to fix it.
So, disable clang-tidy for generated code.
Bug: 162909698
Test: go test android/soong/cc
Change-Id: I0fee137d6170ef4bf6cf641abad572e448aceaa1
Image variants for CC modules were covered to work without VNDK version
from previous commit, but CC genrule has its own image variant rule, so
it should be also updated to generate vendor / product image variant
without VNDK version.
Bug: 316829758
Test: m nothing --no-skip-soong-tests passed
Test: AOSP cuttlefish build succeeded
Change-Id: I425dd425efcc57c7ff8f9964b303ad6f539c3b57
Since VNDK in the main branch will not be finalized, this commit
deletes the build rules that generate the ABI dumps.
Test: make
Bug: 314010764
Change-Id: I2bbab7612d8cbc27312dc4a3c47a0592177918d8
UseVndk is a function to check if the module can use VNDK libraries, but
this function was also used to check if the module is installed in the
treblelized partition (vendor or product). As of VNDK deprecation,
UseVndk funtion will return false even when the module is installed in
vendor / product partition, so we need a separated function to check
this. This change introduces a new function 'InVendorOrProduct' which
replaces UseVndk based on its usage.
Bug: 316829758
Test: m nothing --no-skip-soong-tests passed
Change-Id: Ic61fcd16c4554c355f6005894a4519b044b27fe5
Current CC/Rust Image variations are generated with target VNDK version.
However, this is no longer valid if VNDK is deprecated. This change
generates image variation without version ("vendor", "product") if VNDK
is deprecated.
Bug: 316829758
Test: m nothing --no-skip-soong-tests passed
Test: aosp_cf_x86_64_phone build succeeded
Change-Id: I2387ed8a2632bfd9462621f882a947695ae1653d
libz is a stub library, but needs to be available to runtime apex
because it gets statically linked into bionic linker
Bug: 281077552
Bug: 277651159
Test: m nothing
Change-Id: I04f6f13768d8f9c160ce84202e2003b195176355
LOCAL_STATIC_LIBRARIES, LOCAL_WHOLE_STATIC_LIBRARIES,
and LOCAL_HEADER_LIBRARIES are only exported to Make
so that it can generate module-info.json. Export
ModuleInfoJSONProvider from cc modules so that Soong can
generate the module-info.json entries, and remove the
properties from the generated Android.mk. This will prevent
Kati reanalysis when making some Android.bp changes.
Bug: 309006256
Test: Compare module-info.json
Test: Compare Kati's build.ninja
Change-Id: I6660f6802b9cea46eed553cac12f09a373eeb019
This wasn't needed when fuzzers had their own
lib directories, but because the lib directories
were combined, this caused interactions because
system and vendor libraries were mixed in the
same folder, sometimes overriding each other.
Comments are left with some details about
future issues. Bug has a series of recommendations
to prevent issue again.
The main goal of this patch is to get the fuzzers
working, not fix every issue here.
Bug: 307611931
Test: run vendor fuzzer and check lsof:
android.hardwar 22719 root txt REG 254,94 4350056 3455 /data/fuzz/x86_64/android.hardware.drm-service.<name>.aidl_fuzzer/vendor/android.hardware.drm-service.<name>.aidl_fuzzer
android.hardwar 22719 root mem REG 254,94 4350056 3455 /data/fuzz/x86_64/android.hardware.drm-service.<name>.aidl_fuzzer/vendor/android.hardware.drm-service.<name>.aidl_fuzzer
android.hardwar 22719 root mem REG 254,94 1047232 3464 /data/fuzz/x86_64/lib/vendor/libbase.so
android.hardwar 22719 root mem REG 254,94 4027304 3460 /data/fuzz/x86_64/lib/vendor/libcrypto.so
android.hardwar 22719 root mem REG 254,94 4021632 3467 /data/fuzz/x86_64/lib/vendor/libbinder.so
android.hardwar 22719 root mem REG 254,94 329408 3466 /data/fuzz/x86_64/lib/vendor/libcutils.so
android.hardwar 22719 root mem REG 254,94 508968 3463 /data/fuzz/x86_64/lib/vendor/libutils.so
android.hardwar 22719 root mem REG 254,94 592944 3465 /data/fuzz/x86_64/lib/vendor/libclang_rt.ubsan_standalone-x86_64-android.so
android.hardwar 22719 root mem REG 254,94 2328616 3462 /data/fuzz/x86_64/lib/vendor/libc++.so
and run a system fuzzer
servicemanager_ 27878 root txt REG 254,94 609736 67408 /data/fuzz/x86_64/servicemanager_fuzzer/servicemanager_fuzzer
servicemanager_ 27878 root mem REG 254,94 609736 67408 /data/fuzz/x86_64/servicemanager_fuzzer/servicemanager_fuzzer
servicemanager_ 27878 root mem REG 254,94 4390560 4074 /data/fuzz/x86_64/lib/libvintf.so
servicemanager_ 27878 root mem REG 254,94 13872 4077 /data/fuzz/x86_64/lib/libvndksupport.so
servicemanager_ 27878 root mem REG 254,94 13872 4077 /data/fuzz/x86_64/lib/libvndksupport.so
servicemanager_ 27878 root mem REG 254,94 13872 4077 /data/fuzz/x86_64/lib/libvndksupport.so
servicemanager_ 27878 root mem REG 254,94 11584 4086 /data/fuzz/x86_64/lib/libdl.so
and run a system fuzzer
servicemanager_ 27878 root txt REG 254,94 609736 67408 /data/fuzz/x86_64/servicemanager_fuzzer/servicemanager_fuzzer
servicemanager_ 27878 root mem REG 254,94 609736 67408 /data/fuzz/x86_64/servicemanager_fuzzer/servicemanager_fuzzer
servicemanager_ 27878 root mem REG 254,94 4390560 4074 /data/fuzz/x86_64/lib/libvintf.so
servicemanager_ 27878 root mem REG 254,94 13872 4077 /data/fuzz/x86_64/lib/libvndksupport.so
servicemanager_ 27878 root mem REG 254,94 13872 4077 /data/fuzz/x86_64/lib/libvndksupport.so
servicemanager_ 27878 root mem REG 254,94 13872 4077 /data/fuzz/x86_64/lib/libvndksupport.so
servicemanager_ 27878 root mem REG 254,94 11584 4086 /data/fuzz/x86_64/lib/libdl.so
Change-Id: I91a51d2f1cb537cfaae8379998078188f2b10a98
Overriding android.ModuleContext's implementations of *Specific()
methods in cc.moduleContext and then passing that back to
android.PathForModuleInstall to affect the install path causes
problems if android.ModuleBase.GenerateBuildActions also tries
to call android.PathForModuleInstall directly with the
android.ModuleContext as it gets a different result.
Add InstallIn* methods to the android.Module interface, implement
default versions in android.ModuleBase, and override them in
cc.Module and rust.Module. Use them in android.PathsForModuleInstall
to allow the module to customize the behavior directly.
Test: TestInstallPartition
Change-Id: I7840e07eae34ac4f4d3490b021143d5f33a83626
Its target arch is goldmont, but without xsaves support.
This ensures efficient execution on a broad range of Intel/AMD CPUs used
in Chromebooks, including those lacking xsaves support.
(e.g. Kaby Lake, Gemini Lake, Alder Lake and AMD Zen series)
Bug: 314243939
Test: Build an image with TARGET_ARCH_VARIANT:=goldmont-without-xsaves
Change-Id: I9963cc3356394815f068fc998a9708bdb30c8266
Convert all of the callers of ModuleProvider/ModuleHasProvider to use the
type-safe android.SingletonModuleProvider API.
Bug: 316410648
Test: builds
Change-Id: I6f11638546b64749e451cebbf33140248dc1d193
Convert all of the callers of OtherModuleProvider/OtherModuleHasProvider
to use the type-safe android.OtherModuleProvider API.
Bug: 316410648
Test: builds
Change-Id: Id77f514d68761a262d9ea830a601dbed804bbbe5
Convert all of the callers of Provider/HasProvider to use the type-safe
android.ModuleProvider API.
Bug: 316410648
Test: builds
Change-Id: I73479de1625fa2865b6c73444cd477e50d56dc5a
Convert all of the callers of SetProvider to use the type-safe
android.SetProvider API.
Bug: 316410648
Test: builds
Change-Id: If58f4b5355264ddab2045bc3591a4eac19cd58fc
Convert all of the callers to NewProvider and NewMutatorProvider
to use a generic type parameter instead of an example object.
Bug: 316410648
Test: builds
Change-Id: Ic9cdafc87336e26730d3fd596df05de0e7267542
Using generics for the providers API allows a type to be associated
with a ProviderKey, resulting in a type-safe API without that doesn't
require runtime type assertions by every caller.
Unfortunately, Go does not allow generic types in methods, only in
functions [1]. This prevents a type-safe API on ModuleContext, and
requires moving the API to be functions that take a ModuleContext as
a parameter.
This CL creates the new API, but doesn't convert all of the callers.
[1] https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#no-parameterized-methods)
Bug: 316410648
Test: builds
Change-Id: I3e30d68b966b730efd968166a38a25cc144bd6de
clang silently ignores such things rather than reporting them as errors.
With this change, verbose.log.gz says android10000 instead, as expected.
Bug: https://buganizer.corp.google.com/issues/315788463#comment24
Test: treehugger
Change-Id: I0d92b0747912f28065de0d2dc6b4d33d1c2c9857
Remove the ConvertWithBp2build implementations from all the module
types, along with the related code.
Bug: 315353489
Test: m blueprint_tests
Change-Id: I212672286686a318893bc7348ddd5a5ec51e77a7
Passing the list of all transitive aconfig files to Make causes extra
Kati analysis runs when dependencies are changed in Android.bp files.
Since Make is going to merge them anyways, merge them per-module and
pass a single aconfig file to Make for each module.
Fixes: 313698230
Test: m out/target/product/vsoc_x86_64/system/etc/aconfig_flags.pb
Change-Id: Ifde4826bc93bc06e40338f72b4cb39eed26ca08d
Currently NDK ABI monitoring is enabled by switching boolean flag in
soong code. When this flag is switched, it will enable ABI monitoring in
all release configurations at once.
This change moves the flag from soong code to the trunk-stable flags
framework ("build/release/build_flags.scl") that allows to enable it
only in specific configurations like "trunk-staging".
Test: TH
Bug: 156513478
Change-Id: Ibb810a834c0d756b22782b1a2d8ec5a5e575a4b3
This is part of a larger change to update the flag
PRODUCT_PAGE_SIZE_AGNOSTIC to PRODUCT_NO_BIONIC_PAGE_SIZE_MACRO.
This is to help clarify that this flag doesn't mean the device
will actually work end-to-end with any page size.
Bug: 312541564
Test:
```
source build/envsetup.sh
lunch aosp_cf_arm64_phone_pgagnostic-trunk-userdebug
m
cat out/soong/build.aosp_cf_arm64_phone_pgagnostic.ninja | grep __BIONIC_NO_PAGE_SIZE_MACRO
```
Change-Id: I33033876d0d4a276d1bb962d40315b71a3968c66
When generating vendor/etc/linker.config.pb, STUB_LIBRARIES was used.
Because it lists *all* libraries with stubs regardless of its
install location (vendor or system), using it for vendor
linker.config.pb doesn't make sense. Instead, use vendor-specific
STUB_LIBRARIES, which is named SOONG_STUB_VENDOR_LIBRARIES.
Bug: 313806237
Test: m (aosp_cf_x86_64_phone)
Test: $OUT/vendor/etc/linker.config.pb not listing libz.so
Change-Id: Icd0aaf92d9630c07f58c4739a9f0ac713516db43
Afdo creates more variants to build, and optimizing LTO is costly to
perform. Turn off these two optimizations for eng builds for a faster
build speed.
This reduces total C/C++ invocation time for aosp_arm64-eng by 6.28%.
Test: presubmit
Bug: 307753064
Change-Id: Ibac4269c66a64e896dba2074b607d71a2da37546
This is to handle libz special case. libz has stubs but not an LLNDK.
So, libz.vendor should be treated as non-stub-providing libraries and
Vendor APEX should bundle it if it's used by its contents.
libz will set no_stubs for vendor/product variants.
Bug: 313806237
Test: go tests ./apex/...
Change-Id: I10759d7073838909126f8bfe87654f11aa02fd32
The next CL will need a TestContext parameter in
ContentFromFileRuleForTests in order to retrieve the file rule contents
from the Config. Add it and update all the tests that use it in order
to simply review of the next CL.
Bug: 306029038
Test: go test ./...
Change-Id: Ia4b4c9854017ea3472fa2f8ba42cf7f72720496e
By default clang assumes that on riscv64 jumps are really expensive.
That's probably not true for the kind of SoCs we're dealing with, but
more importantly (see the bug) it causes clang to do loads from the
right hand side of a `&&` before the left hand side has been evaluated.
This found one latent bug in libcore, and it doesn't seem like the best
use of anyone's time to have to chase similar issues if they're going
to be similarly latent for riscv64 when we get clang's default fixed.
Bug: https://github.com/google/android-riscv64/issues/124
Test: treehugger
Change-Id: I640f1b43ea3d2452366ab86e97a9189fa9f5326c
