diff options
author | 2020-04-27 16:44:58 -0700 | |
---|---|---|
committer | 2020-04-27 17:06:58 -0700 | |
commit | c0b442f8a7c42fd3e366d8aea15cee0db4244b36 (patch) | |
tree | bcf3a1fd97b4e207c20a690c11b7fbb7af23ee78 /rust/coverage.go | |
parent | 6c2962e458377d13faae62cc008027f68a6557af (diff) |
[cc_fuzz] Collect shared deps by name, not by module.
cc_fuzz relies on an invariant that's not exactly true. We assume that
for each fuzz target, we'll only have a dependency on a single sanitized
variant of a shared library. In a few instances, this is proven not to
be true, as we end up with a transitive dependency on a shared library
with sanitizer coverage instrumentation, and one without sancov.
This results in breaking the packaging for some fuzz targets. This then
goes on to break `make haiku` in some scenarios.
While this isn't a completely technically correct solution (as we
basically resolve one of the sanitized variants pseduorandomly), it does
resolve the issue for now. Realistically, we should select *both* of
them, and set the DT_RUNPATHS on the shared libraries to point to the
dependencies that have the sanitization that they're expecting. In
practice - this shouldn't break sancov (we might just silently drop some
coverage) or hwasan (we might just silently drop some hwasanification).
I believe that the walk order of VisitDirectDeps is deterministic, and
as such this shouldn't affect the reproducability of fuzz target builds
(and thus won't blow up the Soong rebuilds). ccross@ or dwillemsen@ can
speak better to this than I can though.
Bug: 148306195
Bug: 151102177
Bug: 155123587
Test: lunch flame_hwasan-userdebug && make haiku
Change-Id: I8d4001d93da33e4e5d21f740beb88a20fcc26e2a
Diffstat (limited to 'rust/coverage.go')
0 files changed, 0 insertions, 0 deletions