(This CL is a cleanup, and should be a no-op)
Currently we support three variations of cc api stubs.
1. publicapi stubs, i.e. ndk stubs (empty additional args to ndkstubgen)
2. module-libapi stubs that are also an ndk library (--systemapi --apex)
3. module-libapi stubs that are not an ndk library (--systemapi --apex
--no-ndk)
ndk_libs.bzl was used to differentiate between (2) and (3). This creates
an additional layer of indirection - users will need to modify this
external .bzl file if they would like to add a library to an ndk.
Replace this with an explicit atttibute in cc_stub_suite macro for better UX.
Test: go test ./bp2build
Test: b test //build/bazel/rules/cc:cc_stub_library_tests (added in
sibling CL)
Bug: 299501496
Change-Id: Idd3579e8013bae7a1740534f90d2767df5bac1a5
Just knowing it failed is pretty useless. Tell people how to update
the ABI dumps.
Bug: http://b/156513478#comment43
Test: m ndk # after breaking the ABI
Change-Id: I7ed6a0acf2d1fbd942410678fc6aba2afbc5a2b6
This is the bulk of the "allowlist v2" feature. It will disable bp2build
generation for modules which have transitive dependencies without a
bazel build definition.
This CL includes this mutator, but doesn't register it as a bp2build
mutator (outside of a few unit tests). This allows us to easily iterate
on completion of this feature and ensure there are no launch blockers
before we finalize the change in AOSP.
Bug: 285631638
Test: Unit tests
Change-Id: Ifb0a079c409ca19b02cafa3fab2efa0d3deebc50
Error message in case of not valid "nextAbiDump" included wrong
"prebuiltAbiDump.InvalidReason()". Refactor error message to include
"nextAbiDump.InvalidReason()" instead.
Change-Id: I2581734dd16649af2b282b3459f461658abd3d87
Signed-off-by: Aleksei Vetrov <vvvvvv@google.com>
This no-op refactoring facilitates some upcoming functional changes for
"bp2build allowlist v2". The work requires that the bp2build conversion
mutator be changed from a TopDown mutator to a BottomUp mutator.
Refactoring all bp2build-related methods so that they use Bp2buildMutatorContext
makes it easier to make this functional change without touching tens of
files and multiple projects.
Bug: 285631638
Test: m bp2build
Change-Id: I3d1ef3064146e959c6f0dc315350fc9764bf2bd2
NDK has two ABI checks:
1. Check that prebuilt ABI exactly matches compiled binaries.
2. Check that ABI of level X compatible with level X+1.
The second check used compiled binaries for level X and prebuilts for
level X+1. But this approach may confuse people, because ABI change will
be shown "reversed". For example, adding new field to ABI monitored
binary of level X would be shown as "removed" when compared to level X+1
prebuilt.
This change uses prebuilts for both level X and level X+1. Given, that
prebuilts are checked to match compiled binaries, this should be enough.
Change-Id: If942e4319744bc5a2674cdd65f6a6f664fdfaa7e
Signed-off-by: Aleksei Vetrov <vvvvvv@google.com>
ndk_libary will be converted to a cc_stub_suite target. Its api_surface
attribute will be publicapi
The headers corresponding to this stub target will be added in a followup bug
(tracked in b/300504837)
Bug: 298085502
Test: Added a unit test
Change-Id: If9745083b18e0bcf5ecb89229a0f709b949d401c
Collect all NDK exported headers paths into a file that is used to
detect public types that should be ABI monitored.
Assume that we have the following code in exported header:
typedef struct Context Context;
typedef struct Output {
...
} Output;
void DoSomething(Context* ctx, Output* output);
If none of public headers exported to end-users contain definition of
"struct Context", then "struct Context" layout and members shouldn't be
monitored. However we use DWARF information from a real library, which
may have access to the definition of "string Context" from
implementation headers, and it will leak to ABI.
STG tool doesn't access source and header files, only DWARF information
from compiled library. And the DWARF contains file name where a type is
defined. So we need a rule to build a list of paths to public headers,
so STG can distinguish private types from public and do not monitor
private types that are not accessible to library users.
Bug: 156513478
Test: development/tools/ndk/update_ndk_abi.sh with enabled canDumpAbi
Change-Id: I9fa41e73450a41379638debb3dc56f421e0fb870
Signed-off-by: Aleksei Vetrov <vvvvvv@google.com>
Now migration to STG is complete, hence remove the legacy extraction
mechanisms.
Bug: 156513478
Change-Id: I55b7626e2bfa78c9bb5157ade73d71a97597da72
Signed-off-by: Matthias Maennich <maennich@google.com>
Replace the abidw->stg pipeline by just stg for extraction directly from
ELF/DWARF. This is to migrate to STG entirely.
As a migration tooling, keep the existing method active via
`legacy_use_abidw` as a flag on ndk_library.
Bug: 156513478
Change-Id: Ideaa9908b31591f49f9a167cfa3f3d5c95d8b198
Signed-off-by: Matthias Maennich <maennich@google.com>
STG's native .stg format has been designed with version control in mind
as is the best format to represent STG's internal data representation.
Hence, migrate the ABI representation dump to .stg. That is done by
converting `abidw` extracted xml to stg at build time. STG has builtin
`abitidy` functionality, so `stg` can replace the prior `abitidy` step
to generate the final format.
Bug: 156513478
Change-Id: Ifcac8998ab899637a5d8c54f9e72d79d3e28ec52
Signed-off-by: Matthias Maennich <maennich@google.com>
To support export of NDK APIs in multi-tree, we added functionality to
generate Bazel targets of ndk related Soong module types. Since this use
case does not exist anymore, deprecate this to prevent bitrot
The removed code includes
- `ConvertWithApi2Build` implementation of these libraries, which
generates the Bazel targets in the synthetic `api_bp2build` workspace
- (api) bp2build unit tests for these module types
Test: go build ./cc
Bug: 284029211
Change-Id: Id3278fa119e0ab87f31f39a3783197a81b655e43
We've been fixing this up on the NDK build side for ages. The
platforms/ subdirectory is a legacy thing from very old NDKs. Fix the
install paths to match what the NDK actually uses. This both lets us
delete some code on the NDK side and also makes the platform's output
easier to consume directly without having to wait for an NDK release
(or even a canary).
Bug: None
Test: treehugger
Test: inspected out/soong/ndk/sysroot
Test: build/soong/scripts/build-ndk-prebuilts.sh, imported into NDK
Change-Id: I3c4e0ce6d7960ae0138d1cf803755e4f1e575631
We log an error message, but then carry on and attempt to use the invalid impl, which then panics.
Change-Id: I440cdf728cb32479a10cbaecc5aadbdd97f215de
The module types in scope of this conversion are
1. cc_library and cc_library_shared (non-null llndk or stubs prop)
2. cc_library_headers (all)
For (2), we need some postprocessing on the results of the parser
bp2BuildParseBaseProps. This is necessary because arch and os specific
API exports need to be flattened and added to the generateed API headers
target along NoConfigAxis
e.g.
```
The api equivalent of
cc_library_headers (
name = "lifoo",
deps = select({
"//build/bazel/platforms/arch:arm": ["arm_deps"],
"//build/bazel/platforms/arch:arm64": ["arm64_deps"],
}),
)
should be
cc_api_library_headers (
name = "lifoo",
deps = ["arm_deps", "arm64_deps"],
)
```
For (1), we also need to generate 1:many header api targets so that
arch-specific deps can propagate arch metadata to the top-level
api_domain rule
Test: go test ./bp2build
Test: go test ./cc
Change-Id: Ie40cba1ac8e89f290b3d926c190d5e93abd52859
This is a partial bp2build conversion that only emits the
cc_api_contribution target of ndk_library. We also need to convert this
to cc_stub_suite eventually to enable building vendor/product API
domains with Bazel
Also create an enum for the three known Multi-tree API surfaces (will
likely be expanded in the future)
Test: go test ./bp2build
Test: b cquery //bionic/libc:libc.ndk.contribution --output=starlark
--starlark:expr="providers(target)"
Change-Id: Idb24871ba20aae132b61eb31ef35c917cacae9e1
The new property will be used to determine the header file contributions of
ndk_library(s) to the Public API surface. This should be a no-op for
regular Soong builds.
This will be used by a future bp2build converter to populate
the BUILD files for Multi-tree `cc_api_contribution` targets
(Also noticed that sdk_test.go was never added to testSrcs, which this
CL should fix)
Test: go test ./cc
Test: TH
Change-Id: Ieea093e4aac68e341c6414b6cafe02c441643cdf
Looks like new versions of the toolchain have an error about mismatching
the definitions used in the stubs with the builtin definitions. Since we
don't care about this when building stubs, ignore it by disabling the
builtin definitions.
Bug: N/A
Test: Build platform with ToT LLVM compiler.
Change-Id: I4e449c5fb96d0d5442fd57a7fea02ba69463324b
This change contains a prototype implementation for multitree. Several
interfaces and modules are added.
1. Imported/Exported
Modules implementing Exportable interface can export artifacts to other
components. "imported_filegroup" modules can import generated artifacts from other exported modules.
2. Multitree metadata
It contains information about imported/exported modules in each
component, and can be generated via "m update-meta".
3. cc library stub
It's based on prototype stub libraries. It uses imported/exported
mechanism to expose a C API, with a map.txt file and header files.
Bug: 230448564
Test: m
Change-Id: Id7ff7618e2c630c5617a564d8b23b60a1cc9c8e8
abidw doesn't currently handle top-byte-ignore correctly. Disable ABI
dumping for those configs while we wait for a fix. We'll still have
ABI checking coverage from non-hwasan builds.
Bug: http://b/190554910
Test: treehugger
Change-Id: I0e29979f8c212c43e0d1beea737abcd7fd0119d7
Similar to `tidy_disabled_srcs`, a `tidy_timeout_srcs` list
can be used to include all source files that took long to compile
with clang-tidy. Files listed in `tidy_timeout_srcs` will not
be compiled by clang-tidy when `TIDY_TIMEOUT` is defined.
Bug: 201099167
Test: TIDY_TIME=90 make droid tidy-soong_subset
Change-Id: Ie0bfda66caae4445d10117ceefa1b5b8c1ecf256
Used as a supplement to C/C++ srcs to disable
clang-tidy for selected srcs, when a library
contains many files in srcs and only some of them
are too large to compile with clang-tidy.
Test: WITH_TIDY=1 TIDY_TIMEOUT=90 make tidy-soong
Bug: 198098397
Change-Id: Ib32eb0e46ddbc717999797717bfd8c57e182ee88
Both processes might consume a large amount of memory when analyzing
library ABIs. By chaining them via a pipe we keep the same
representation twice in memory. That can introduce a problematic peak
memory consumption. Hence, split them apart into separate rules that
depend on each other.
Bug: 191235788
Test: m out/soong/abi-dumps/ndk/28/x86_64/libc/abi.xml
Signed-off-by: Matthias Maennich <maennich@google.com>
Change-Id: Ia0264a5ede5b2c2a3c2e3fbe968c11d36acf33c2
I'm not sure why these targets are getting built as part of the sdk
build anyway, but we don't need them.
Test: treehugger
Bug: http://b/156513478
Bug: http://b/190394921
Change-Id: I1ea0e75f459ad7cad648f96b67a4f2424d36fda7
The local diffing behavior is currently flagged off so we can land
this in stages.
Test: pytest cc
Test: treehugger
Test: development/tools/update_ndk_abi.sh
Test: m ndk
Bug: http://b/156513478
Change-Id: Iccb314411bc74ea3ddfea8b85b0539709295f65a
This is unused and doesn't work with our current API review process
anyway (un-drafting an API won't be flagged for API council review).
Test: treehugger
Bug: None
Change-Id: I6d8fcc9885b82dac5ada7772d9e3fb9101524ece
Native bridge modules never need to build against NDK stubs, so
don't create SDK variants. Also clear the sdk_version property
for modules that don't have SDK variants so that later code doesn't
use it to trigger SDK behaviors.
Test: m checkbuild
Change-Id: I1920fa82e9fab06235f01a62624382efa16cc6e3
Storing ndkKnownLibs prevents multiple tests from running in parallel
as one may be writing to the list while another is reading from it.
Store it in the config so each test has its own copy.
Test: go test -race ./apex
Change-Id: Iba57c9494012c9e0ae9e5ffaa63b9b2bd2c77492
The stubs methods are very specific to cc for now, move them out
of LinkableInterface so they are not shared with rust. Instead,
create a cc.Module.library field that contains the libraryInterface
to simplify calling libraryInterface methods on cc modules.
Test: all Soong tests
Test: no change to Soong outputs
Change-Id: I0289d866ce1f7a765631fe3101a62b1b4988ba1c
Prepare for making the relationship between an llndk_library stubs
module and the cc_library implementation module explicit by
adding an llndk_stubs property. Each cc_library will be updated
to point to its llndk_library, and the llndk_library name will
be changed to make the .llndk suffix explicit. Then the implicit
connection and suffix can be removed.
Bug: 170784825
Test: m checkbuild
Change-Id: I6b0482a3f286ec29b2e928551aa4317749f2b499
Implement stubsVersions on *llndkStubDecorator and *stubDecorator to
handle the special cases in versionSelectorMutator.
Test: m checkbuild
Change-Id: Idc985c52f91450df42c0275b2b2acef3f2ed8868
Move the CRT objects into the version mutator and retire the
ndk_api mutator.
Test: no change to build.ninja or Android-${TARGET_PRODUCT}.mk
Change-Id: Ibbbde323e3e0e8e4702dda4f3828a49786280118
The ndk_api mutator is similar to the version mutator. Move the
ndk_library ndk_api variations into the version mutator instead,
which will help later when consolidating the stubs handling
between NDK, LLDNK and Apex libraries.
Test: No change to build.ninja or Android-${TARGET_PRODUCT}.mk
Change-Id: I51417cf669265762c15f7289e1dc186d017ef4a9
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
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
