In the previous mode, building Rust code using certain intrinsics would
fail on arm32 since our runtime is armv7, but our codegen was arm.
Test: cd external/rust; mma
Bug: 169245712
Change-Id: Ie800486b39325486f5ff319e46632df2a6987391
Experimental global ThinLTO mode for compilation time evaluation.
Bug: 169004486
Test: GLBOAL_THINLTO=true m
Change-Id: I2ff06397be8b65c7972f1e5f09ab1496949567ee
They used to be listed to not have this treatment, but we are
baselining the existing warnings and making them errors instead.
Bug: 154317059
Test: m
Change-Id: I306b5a07d1b771cc0061aaac44f881f40fbe85ed
Merged-In: I306b5a07d1b771cc0061aaac44f881f40fbe85ed
linux_bionic_arm64 is the new host target using Bionic as libc. This
change adds a new Soong config Host_bionic_arm64 that enables the
target.
This change also amends firstTarget() function to handle the case when
the available targets for an OS have different arch families. In that
case, first target is selected for each of the arch family. This is
needed in the (rare) care when both linux_bionic_x86_64 and
linux_bionic_arm64 targets are enabled.
Bug: 159685774
Test: add "Host_bionic_arm64": true to out/soong/soong.config and run
./build/soong/soong_ui.bash --make-mode --skip-make
out/soong/host/linux_bionic-arm64/bin/aarch64-linux-bionic/crosvm
Change-Id: I0885e49379f6ee216c6e82adbb1230655171a7a5
A host target is considered as being cross-compiled when the target
can't run natively on the build machine. For example, linux_glibc/x86_64
is a non-cross target on a standard x86/Linux machine, but is a cross
host on Mac. Previously, whether cross or not was a static attribute of
an OsType. For example, Windows was always considered as cross host,
while linux_bionic was not. This becomes a problem when we support more
host targets like linux_bionic/arm64 which should be cross-host on
standard x86/Linux machines.
This change removes HostCross from the OsClass type and instead adds a
property HostCross to the Target type. When a target is being added, it
is initialized to true when the target can't run natively on the current
build machine.
Bug: 168086242
Test: m
Change-Id: Ic37c8db918873ddf324c86b12b5412952b0f2be2
We should override log-dir with the environment variables if its set.
This is needed in our integration tests and generally to allow for
user-overrides.
Test: RBE_log_dir=`pwd`/rbelogs mmma external/boringssl
Change-Id: I3d316a2d60122c42f5c3b5dfede4037362a7b5f1
The test case I removed is invalid. The codename has had its int
assigned, but the config claims it is not final.
If this ever does need to be supported it's just a matter of making
sure the Q -> 29 mapping (or whatever) in the finalized codenames map
in android/api_levels.go.
Test: treehugger
Bug: http://b/154667674
Change-Id: I4f42ec2fd4a37750519ee3937938a1c65b6bb1e8
Keeping the int constant around for now as FutureApiLevelInt because
it's still useful in places that haven't adopted ApiLevel yet for
testing if their non-ApiLevel API level is current or not.
Test: treehugger
Bug: http://b/154667674
Change-Id: I47a7012703f41fdeb56f91edf9c83afa93042deb
Bug: http://b/119560349
Bug: http://b/168925229
To build with PGO instrumentation, the link step also needs
-fprofile-generate flag. Omitting this will result in a linker error.
This surfaces if module A depends on module B but PGO is used only for
module B.
Previous uses of PGO were avoiding or working around the issue but to
accommadate recent changes, this CL propagates the PGO linker flag to
module A.
Test: pgo-coral-config1 in release branch, TH
Change-Id: I12f6243152d4f5ea5526fbce03c25dba232ddab7
We previously disabled inlining and unrolling completely during ThinLTO
in absense of PGO profile. For global ThinLTO, we want to better balance
binary size and performance.
We evaluated a number of combination of heuristics with global ThinLTO
configuration:
binary size change
no LTO baseline
no inline, no unroll -0.54%
no inline, unroll -0.50%
import-instr-limit=5, unroll +0.02%
import-instr-limit=10, unroll +0.13%
Loop unrolling does not contribute much to the binary size, therefore
it is re-enabled.
import-instr-limit=5 balances the binary size savings from ThinLTO and
size incrase due to additional optimisation.
Bug: 78485207
Bug: 169004486
Test: TreeHugger
Change-Id: I1c21153605e2ae42daa8857b06e27c081ee8ad85
Can happen if OUT_DIR is set on an absolute path.
Test: env RBE_remote_disabled=true OUT_DIR=/home_2/tmp/out m
Bug: 169048540
Fixes: 169048540
Change-Id: Ia6b91b13142d84e54d0dee8b4e04a91ad2cecc36
Intellij PSI/UAST reflects into java.base causing
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.intellij.util.ReflectionUtil (file:/mnt/ssd1/out/master/soong/host/linux-x86/framework/metalava.jar) to method java.util.ResourceBundle.setParent(java.util.ResourceBundle)
WARNING: Please consider reporting this to the maintainers of com.intellij.util.ReflectionUtil
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Upstream bug https://youtrack.jetbrains.com/issue/IDEA-210683
Bug: 168689341
Test: make checkapi
Change-Id: Ibc8954d83d5962b3cd0ea1bac9a62f6ccfc88c6c
-fwhole-program-vtables cflag requires LTO to be enabled. Some projects
add this flag unconditionally, breaking builds that turn off LTO.
Make this an LTO property so that build system will handle adding the
flag when LTO is on.
Test: build
Bug: 169004486
Change-Id: Ifce12c09e1d6b8c2807314c3bb982b076efcaaa4
Installation path of prebuilt_firmware varies accoding to target
partitions. When it is for system, it installs a file in
/system/etc/firmware while it installs in /vendor/firmware for vendor.
We'd better be consistent about installation path when it is
for APEXes regardless of target partition. Otherwise, ueventd would need
to scan both /apex/*/etc/firmware and /apex/*/firmware.
Having /etc prefix for prebuilt modules helps module owners to predict
the layout of the contents.
Bug: 162701747
Bug: 167942098
Test: soong tests
Test: loading vibrator firmware from vibrator apex (sunfish)
Change-Id: I7a7105026426f8a7a156bc947304930f761c81f3
The current state of linkage is that device targets always link
libstd dynamically except for rust_ffi_static which requires a static
libstd linkage. However this prevents producing rust_ffi_static
modules which depend on other Rust libraries as those dependencies
will link libstd dynamically and cause a collision. We also want our
rust_test modules to statically link in libstd as well.
This adds a linkage mutator for rlibs that creates a variant for each
libstd linkage. Dependent modules can then select the variant that
matches their linkage of libstd.
Also fixes an issue where installation paths were being generated for
rlibs and static libs even though they weren't being installed. This broke
when adding the linkage mutator as Make would complain about multiple
targets producing the same output.
Bug: 168729404
Test: rust_ffi_static module with other rustlib dependency can be built.
Change-Id: I955b484bf5809e8fc5517750c7f8df82d3ca8895
Handling of API levels within Soong is currently fairly difficult
since it isn't always clear based on context what kind of API level a
given string represents, how much canonicalizing and error checking
the code receiving the string are expected to do, or how those errors
should be treated.
The API level struct does not export its raw data, so as to keep its
"constructor" private to the android package, and to prevent misuse of
the `number` field, which is only an implementation detail for preview
API levels. API levels can be parsed with either
`android.ApiLevelFromUser`, which returns any errors to the caller, or
`android.ApiLevelOrPanic`, which is used in the case where the input
is trusted and any errors in parsing should panic. Even within the
`android` package, these APIs should be preferred over direct
construction.
For cases where there are context specific parsing requirements, such
as handling the "minimum" alias in the cc module,
`nativeApiLevelFromUser` and `nativeApiLevelOrPanic` should be used
instead.
Test: treehugger
Bug: http://b/154667674
Change-Id: Id52921fda32cb437fb1775ac2183299dedc0cf20
Yi Kong