Support Additional outputs from compile and link steps for C++

[SoftwareApe]

Description of the feature request:

We need a way to persist "extra" files on compilation, linking, binary generation, etc. for C++ builds.

What underlying problem are you trying to solve with this feature?

We need a certified code coverage measurement. For this we're currently using SquishCoco. However Bazel only supports GCC coverage. I.e. it only supports objects producing extra .gcno files, e.g. foo.o gets generated with foo.gcno.

Now SquishCoco adds more outputs.

foo.o adds foo.o.csmes bar.so adds bar.so.csmes bar.a adds bar.a.csmes baz adds baz.csmes (binary)

After baz runs it adds baz.csexe for the execution report.

I checked in the Bazel code and it seems quite difficult to address this. Removing the extra flags when using the --collect_code_coverage command is easy.

When it comes to persisting the instrumentation files it gets more tricky, since the code is very GCC-centric here. Even if I change the .gcno to .o.csmes, the output of the compilation step survives the sandboxing 👍, but the output from linking the library doesn't, e.g. the .so.csmes 👎.

What we would need is a way to persist extra files during compilation, linking, binary generation, and ideally from testing as well, so that caching can work it's magic. These rules are implemented in native code and can't be changed, except by changing Bazel.

Something like https://github.com/bazelbuild/bazel/issues/17237 I think would enable us to do what we need, but there's no progress here for a long time. Essentially I think code coverage measurement should be a quite basic requirement for a build system. Supporting every special tool in the native code is probably prohibitive, so I think the current approach of hardcoding .gcno into the system is the wrong way. Every tool has their own set of files it creates. We should have an escape hatch here so that we can define which extra files get generated under which conditions, ideally systematically with some callbacks.

Squish Coco is just one example, other teams use Parasoft and have the same issue. CTC++ I think would generate the same issues as well.

Which operating system are you running Bazel on?

Ubuntu 20.04

What is the output of bazel info release?

release 6.1.0

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

No response

Have you found anything relevant by searching the web?

No, except for a presentation by SpaceX which said they managed to get coverage out of Bazel. Since Aerospace is also safety critical I assumed they must use some certified tool, however the presentation didn't mention much.

Any other information, logs, or outputs that you want to share?

No response

[github-actions[bot]]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 90 days unless any other activity occurs. If you think this issue is still relevant and should stay open, please post any comment here and the issue will no longer be marked as stale.

[brentleyjones]

@bazelbuild/triage not stale

[pzembrod]

I'll close this as a duplicate of two issues, #24990 (Add custom additional_outputs to cc_common.link) and #22036 (Add additional_outputs parameter to cc_common.compile).