Windows feature generate_pdb_file should be applicable to opt builds

[sunjayBhatia]

Description of the problem / feature request:

We would like to generate .pdb files for release builds of Envoy for Windows for use debugging potential production issues. This works well with Bazel building locally as all intermediate/compiler/linker generated files live on the host. We use opt mode, the MSVC cl /Z7 option, and linker options /DEBUG:FULL. However, building Envoy with RBE in CI, the expected .pdb file output is not accessible. It is not an explicit output of the cc_binary rule on Windows and is not downloaded to the host running the build (or presumably any rules that were to depend on the binary target, not sure if a genrule workaround could work to grab the relevant file). This is in contrast to Linux where cc_binary rules create an implicit <target>.dwp target that can be used to access debug info. Using --remote_download_outputs=all (the default) or --features=generate_pdb_file does not work as the feature is only enabled for dbg and fastbuild compilation modes.

It would be great if the restriction of the feature to dbg and fastbuild modes was relaxed

Feature requests: what underlying problem are you trying to solve with this feature?

See above, generate .pdb files as when building Envoy with RBE in opt compilation mode.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Build a cc_binary rule in opt compilation mode and link with MSVC link /DEBUG options to generate a .pdb file in RBE on Windows. See that no .pdb file is downloaded even when using --features=generate_pdb_file or --remote_download_outputs=all.

What operating system are you running Bazel on?

Windows (2019)

What's the output of bazel info release?

release 3.6.0

Have you found anything relevant by searching the web?

Not as of yet

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

Not as of yet

Cross-posting from bazelbuild/rules_cc#94 to get more visibility

[sunjayBhatia]

Related PR for compiler PDB support that has gone unreviewed which might ultimately be the better answer

[ulfjack]

Which PR?

[sunjayBhatia]

Whoops, didnt paste the link: bazelbuild/rules_cc#78

[wrowe]

Note PR#78 speaks to .obj creation, and a resulting .lib with .pdb output merged from each individual object compilation. As a stop-gap, to capture the .pdb from in opt build link step, bazelbuild/rules_cc#94 may be the workaround; but it would be helpful if the generate_pdb_file feature could toggle the opt compilation /Z7 (or /Zi in the PR#78 case) and linkage with /debug:full /opt:ref and /opt:icf flags - which cause the coff debugging from /Z7 or the source .pdb from /Zi to be emitted as the binary.pdb symbols output file.

Consider these Issues #12698 and bazelbuild/rules_cc#94 overlapping (most discussion in the later Issue) and the proposed workaround is now present on bazel and rules_cc repository master branches; 6dc941e and bazelbuild/rules_cc@5689775 respectively.

The remaining question is whether all of the extra copts and linkopts manipulation is up to the consuming project, or if this should be a simple toggle. I think we can close one issue or the other and leave future discussion on a single bazel or rules_cc issue.

[github-actions]

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 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

[github-actions]

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please reach out to the triage team (@bazelbuild/triage). Thanks!