`--fission=yes` alone does not generate real `.dwp` files

[rrbutani]

My understanding is that --fission is supposed to be a cross-platform way to generate separate debug info files for C/C++ rules (this is definitely stretching it a bit; I think --fission is intended to be .dwo/.dwp specific – that is, it's not supposed to generate .dSYMs on macOS and .pdbs on Windows).

In practice, --fission=yes alone does not generate non-empty .dwp files; --features=per_object_debug_info must also be specified.

This is because unix_cc_toolchain_config.bzl's cc_toolchain_config does not enable the per_object_debug_info feature by default.

Passing in --features=per_object_debug_info to enable it manually (i.e. in a .bazelrc) is sub-optimal because this breaks compilation on other platforms like macOS where -gsplit-dwarf has different behavior and will not produce .dwo files (on macOS debug info lives in the .o files – as in there is no .dwo equivalent – and running with -gsplit-dwarf when producing a binary will produce a .dSYM file, the .dwp equivalent).

It seems better to have the toolchain – which knows the platform it targets and has enough information to choose to enable this feature – handle this rather than to foist this onto users (afaik there isn't a create way to deal with this outside of the toolchain anyways; best I can come up with is build:linux --features=per_object_debug_info and then requiring --config=linux when building for Linux, etc.).

I think it's actually safe for us to enable the per_object_debug_info feature by default on Linux because it's effectively gated on fission:

• the per_object_debug_info feature (which we cans see introduces the -gsplit-dwarf flag) lives here
  • in the above we can see that it's gated on per_object_debug_info_file
• per_object_debug_info_file comes from here in Bazel and is ultimately set by this bit in CompileBuildVariables.setupSpecificVariables when given a real dwoFile
• that function is called from CcCompilationHelper.setupCompileBuildVariables which just threads through the dwoFile it's called with
• ^ is called several times from functions like CcCompilationHelper.createSourceAction which provide a dwoFile to ^ if they are passed generateDwo = true
• ^ is ultimately called from functions like CcCompilationHelper.createCcCompileActions which ultimately ask the current ccToolchain (CcToolchainProvider.shouldCreatePerObjectDebugInfo) if generating per object debug info is enabled for the current feature configuration
• CcToolchainProvider.shouldCreatePerObjectDebugInfo returns true only if fission is enabled and if the per_object_debug_info feature is enabled

steps

While we're still using unix_cc_toolchain_config.bzl there's not much we can do about this. These are notes for what to do when we eventually vendor in a version of unix_cc_toolchain_config.bzl (and potentially macOS and Windows host counterparts as well).

• enable the per_object_debug_info by default
  • this should make it so that we don't have to gate the test added in Include the symlinked dwp/objcopy/strip files in the toolchain #108 on Linux and so we don't have to specify the per_object_debug_info flag explicitly; passing in --fission=yes should be sufficient
• ensure that --features=per_object_debug_info sets the debug level high enough to generate .dwo files
  • this comment has some context and per_object_debug_info does not work with Clang 12 bazelbuild/bazel#14038 tracks this issue and Add -g in per_object_debug_info for Clang 12 and GCC 11 bazelbuild/rules_cc#115 has a fix
  • if Add -g in per_object_debug_info for Clang 12 and GCC 11 bazelbuild/rules_cc#115 doesn't get merged we should do something like it when we switch to using our own unix_cc_toolchain_config.bzl
  • we should also remove the -c dbg transition workaround that was added in Include the symlinked dwp/objcopy/strip files in the toolchain #108 when we do this

It's not clear yet whether this is doable/sensible but it'd be nice to have --fission (or some flag like it) cause rules_cc to generate split debug info for all the targets that support it. This would mean:

• generating dSYM files on macOS (but only on the final link step)
  • there's stuff in the osx crosstool toolchain config for this but it seems to depend on build variables from the objective-C ruleset?
  • some of the apple rules have support for this (--features=apple_generate_dsym) but I don't think that helps
  • dsym support on MacOS bazelbuild/bazel#327 remains open
  • we could build this kind of workaround into our link commands? but the question remains how to get rules_cc to give us top-level exposed .dSYM targets
• no idea what the story is for Windows
  • there's generate_pdb_file which seems to work similarly enough to .dwp files except that it's output_group based instead of a separate target (it'd have been nice to just have a debug_info output group for all these files...) and the logic seems to live inside of bazel instead of in the toolchain features

All in all, probably not pursuing. We should do the first thing though.

open questions

• I'm confused about what the features associated with a cc_toolchain actually do.
  • they definitely don't enable those features by default for the associated toolchain
  • they don't seem to indicate what features a toolchain supports (i.e. the per_object_debug_info feature is not associated with the toolchains unix_cc_toolchain_config.bzl produces for macOS but if I enable the feature manually with --features=per_object_debug_info I can see that feature's flags being added to the commands executed)
  • they definitely do not influence toolchain resolution
  • cc_common.create_cc_toolchain_config_info ultimately is backed by ccToolchainConfigInfoFromStarlark but other than getting stored here I haven't really been able to tell what the features that are passed in get used for. I'll look into this more later.

[keith]

I submitted bazelbuild/bazel#14777 which solves one of the concerns above

[keith]

Thanks for this write up! It was super useful when tracing back android fission support which I'm working on here bazelbuild/bazel#14765