search

bazelbuild / bazel

a fast, scalable, multi-language and extensible build system
https://bazel.build
Apache License 2.0
23.04k stars 4.03k forks source link

Support dSYM generation for cc_binary / cc_common.link #16893

Open keith opened 1 year ago

keith commented 1 year ago

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 https://github.com/bazelbuild/bazel/blob/1620b6eb0f19ef60a87ede9eb7b69ce5d0ee78ce/src/main/java/com/google/devtools/build/lib/rules/objc/ObjcVariablesExtension.java#L232-L234

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 commented 1 year ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 1 week ago

@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).