This lets us test uninitialized variables even if we change the defaults
for -ftrivial-auto-var-init.
Bug: 131390872
Test: AUTO_UNINITIALIZE=true m
Change-Id: I2b4473a0547dc9c4d9f081d8af2d283f17f66f7a
This CL adds RBE support to javac, r8, and d8 rules which is only
enabled if respective environment variables are set.
Test: an aosp_crosshatch build with and without the new variables.
Change-Id: Ic82f3627944f6a5ee7b9f3228170c2709b1bfcb8
This reverts commit 5df3b11f78.
Reason for revert: re-land with a fix
Fix a broken soong test
Add implicit dependency (libprofile-clang-extra) to make a test pass.
Bug: n/a
Test: m
Change-Id: I0b179199bc032501354f8e24782837453781bd8c
VNDK APEX is supposed to contain "vendor" variants of VNDK libraries.
This is different from normal APEXes which have "apex" variants.
Bug: 146758869
Test: build / flash / boot
Change-Id: I5e035678c337334092616b58d2e0e404788a6639
Exempt-From-Owner-Approval: Got ORV, but rebased with resolving merge conflicts.
First round of cleaning. Remove VNDK libraries that
already have identical variants.
Bug: 148082691
Test: Build success
Change-Id: I97f946a2cbf459b607a73e766db9fb8d7655f220
This file contains only a list of VNDK libraries that are allowed to
have different VNDK variant behaviors.
Test: N/A
Change-Id: I9e395b82b8006133294cf325e4626c1b34053588
Some NDK stub libraries are tagged with "LLNDK" in lsdump_paths.txt
because they are not in NDK, and their base module names are in LLNDK.
This commit excludes those NDK stub libraries from lsdump path list.
Test: make findlsdumps
Bug: 147409497
Change-Id: I7a72758ba40d5f5bda8c436dd0b22e5efda03a32
Autofdo generates profile for an instruction even if there is no debug
information associated with it or no debug information associated with
the function. A bogus offset will be produced in the profile. Add the
flag to suppress Clang from generating error for such cases.
Test: build with ETM profile
Bug: 147844018
Bug: 79161490
Change-Id: I37da1ba3a4962072ccdf01f79fbf2c2b4c77b56b
Pattern initialization helps us make C++ safer, while not altering the
semantics/usage of C++ (as zero init does).
Bug: 131390872
Test: Local testing. Parts of CTS.
Change-Id: I9705ca3b724208647f0eab0a704f6f360206d482
This reverts commit 7cb4d378e7.
Test: m
Test: ALLOW_MISSING_DEPENDENCIES=true DIST_DIR=out/dist ./art/tools/dist_linux_bionic.sh -j80 com.android.art.host
(in the master-art-host branch)
Change-Id: I9beca73aafdf42f03bfa19cf1634b2641dac417b
This reverts commit 956305c61c.
Reason for revert: broke master-art-host branch
Exempt-From-Owner-Approval: reverting a bad change
Change-Id: Id7faed4ee85328c7c65847a3543ea9e67a3d50b3
This relands I12a0f907753fefd1997ab8b4ea2ac331234093cf along with
a fix to blueprint for absolute paths.
Store the current working directory and then change to the root
directory so that all file accesses must go through helpers in
the android package that properly track dependencies.
Change-Id: I24ac485677aa102eec1a2521d16820da6ee1ae77
Fixes: 146437378
Test: m checkbuild
Test: m OUT_DIR=/tmp/out nothing
Instead of linking the unwinder statically into every binary, link it
dynamically, by exporting the symbols from libc.so. This has a number
of advantages:
- Reduces image size (system.img size decreases by 1.7MB on walleye-userdebug,
and 1.2MB on crosshatch-userdebug).
- Allows us to easily change/upgrade the unwinder throughout the system,
including vendor prebuilts.
- Allows code outside of libc++ to define custom personality routines.
Previously, personality routines would call the unwinder routines in the
local binary, which would cause problems with unwinders with global state
(such as the libgcc unwinder) if the copy of the unwinder used for unwinding
(normally libc++'s copy) were different from the copy linked against the
personality routine.
Bug: 144430859
Change-Id: I3b2a4a3ee58c6777989f811e19a3aeb47c0945bd
Store the current working directory and then change to the root
directory so that all file accesses must go through helpers in
the android package that properly track dependencies.
Fixes: 146437378
Test: m checkbuild
Change-Id: I12a0f907753fefd1997ab8b4ea2ac331234093cf
This change fixes a bug that test modules (cc_test or its sub types) are
unconditionally considered as non-installable if they are configured to
not available for platform. The rationale behind the decision was that
an APEX variant of a module doesn't need to be installed to the device
because the variant will anyway be included in the APEX. However, it's
wrong for test modules. They are not included in the APEX, but should be
installed to /data/nativetest*.
One might think that we need to make the tests available for the
platform (i.e. apex_available: ["//apex_available:platform"]). This
however doesn't work if the libraries that the tests should link against
are configured to be not available for the platform, which currently is
the case for the ART tests.
Bug: 146995717
Test: m
Change-Id: I51843f5b4ea0a418c64c63784347231590cd3c35
Stephen Hines