Support dSYM generation for cc_binary / cc_common.link

[keith]

Description of the feature request:

Currently on macOS if you'd like to generate dSYM you have to go through some objc provider for the final link. Technically any cc_binary could have a dsym, and for other rules that don't particularly depend on objc, like swift_binary, it would be ideal if they could also produce a dsym. It appears to me that even if we made the required crosstool changes setting the variables for dsyms is gated behind various objc variables

bazel/src/main/java/com/google/devtools/build/lib/rules/objc/ObjcVariablesExtension.java

Lines 232 to 234 in 1620b6e

	private void addDsymVariables(CcToolchainVariables.Builder builder) {
	builder.addStringVariable(DSYM_PATH_VARIABLE_NAME, getShellEscapedExecPathString(dsymSymbol));
	}

I think in general this is known as part of moving to CcInfo for linking, but I couldn't find a tracking issue

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

No response

Which operating system are you running Bazel on?

macOS

What is the output of bazel info release?

release 6.0.0rc3

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 response

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

No response

[bensternlieb]

I have the same issue I think. The bazel plugin for clion uses a compile line that looks like this:

$ c++  -o main -g2 main.cc 

This generates both a main executable and a a main.dSYM directory. In a cc_binary target, I can't do the same; I've tried

 bazel build --apple_generate_dsym //simple:main
 bazel build -c dbg --apple_enable_auto_dsym_dbg -s //simple:main
 bazel build -c dbg --apple_enable_auto_dsym_dbg --apple_generate_dsym -s //simple:main

and other variants and have yet to produce a dSYM file.

[jiawen]

I just ran into this today. Adding to what @bensternlieb did, I also tried adding the more modern flags:

--apple_generate_dsym --output_groups=+dsyms and --copt=-g --cxxopt=-g --define=apple.add_debugger_entitlement=yes (and the Cartesian product of all of them!)

@keith Can you suggest a workaround? Is this what macos_command_line_application is for?

I started down this rabbithole because I wanted to use Instruments.app to profile a cc_binary and was surprised that it Failed to gain authorization. Ad hoc signing with codesign -s - worked, after which I discovered --define=apple.add_debugger_entitlement=yes.

I think the community would appreciate a bit more detail in the common info on how this all fits together (not the most exciting documentation to write, I know. And I'm happy to contribute as it's sorta part of my day job).

[keith]

as a workaround for any cc_binary you can manually create the dsym after your build with dsymutil --flat -o foo.dsym path/to/binary, I haven't checked up on the current state of this

[jiawen]

as a workaround for any cc_binary you can manually create the dsym after your build with dsymutil --flat -o foo.dsym path/to/binary, I haven't checked up on the current state of this

Ha, you're right. I ran this yesterday without --flat and thought it didn't work - but it does. lldb just refused to set a breakpoint by line, setting it by function name worked fine though. 🤷

For the record, @keith's workaround works fine even for optimized builds. I used bazel build -c opt --copt=-g //package:my_cc_binary, followed by dsymutil --flat -o /tmp/foo_flat.dsym bazel-bin/package/my_cc_binary (without --flat works too, it just makes a .dSYM bundle with an identical payload inside). lldb bazel-bin/package/my_cc_binary, (lldb) add-dsym /tmp/foo_flat.dsym, (lldb) breakpoint set --name main, (lldb) run, and off you go.

[jiawen]

@keith Additional notes for the record. I've confirmed that macos_command_line_application is a nice workaround (with the minor annoyance of having to wrap the code in an cc_library (objc_library not required) and adding minimum_os_version).

• -c dbg --apple_generate_dsym
  • Works: made <my_macos_cli_app>.dSYM
• -c opt --apple_generate_dsym
  • Works: made <my_macos_cli_app>.dSYM
  • --copt=-g is not required. Adding the flag results in identical binaries and dSYM bundles.
  • dsymutil -s <my_macos_cli_app> | grep N_OSO shows that the binary contains embedded debug symbols.
• -c dbg
  • Debug build by default embeds debug symbols but does not generate any sidecar dSYM bundles.
  • dsymutil -s <my_macos_cli_app> | grep N_OSO shows that the binary contains embedded debug symbols.
  • <my_macos_cli_app>.dSYM does not exist.
• -c opt
  • Optimized build with default settings do not embed symbols and does not generate any sidecar dSYM bundles.
  • dsymutil -s <my_macos_cli_app> | grep N_OSO returns empty.
  • <my_macos_cli_app>.dSYM does not exist.