Setting --compilation_mode=opt results in a binary with debug info + symbol table not being stripped
#3917
Comments
Strum355
added a commit
to sourcegraph/sourcegraph-public-snapshot
that referenced
this issue
Apr 15, 2024
Our rust binaries (e.g. scip-ctags/syntect_server) were being built in some mix of opt & fastbuild mode[1]. Unlike with Go where there is no release/debug mode flag, Rust requires opting into optimized release builds. We can do that automagically when building any oci_image target with the power of ✨ transitions ✨ This has the side-effect of our Go binaries no longer being stripped & containing debug symbols, see bazel-contrib/rules_go#3917 Also to note, [in Cargo.toml we opt into debug symbols in release mode](https://sourcegraph.com/github.com/sourcegraph/sourcegraph@nsc/bazel-release-mode-rust/-/blob/docker-images/syntax-highlighter/Cargo.toml?L67%3A11-70%3A9). Is this preserved by this PR for bazel[2]? [1] `strings` on the binaries showed the 3rd-party crates having `k8-opt` filepath names e.g. ``` $ / # strings syntect_server | grep k8- /tmp/bazel-working-directory/__main__/bazel-out/k8-opt-exec-ST-13d3ddad9198/bin/external/crate_index__onig_sys-69.8.1/onig_sys_build_script_.runfiles/crate_index__onig_sys-69.8.1 ``` but the final binaries (and the 1st-party crates) themselves were being built in fastbuild mode. See https://github.com/sourcegraph/devx-support/issues/790 for original point of contact [2] It seems like it may be preserved, but I dont know how reliable this is for Rust binaries ``` $ file bazel-bin/docker-images/syntax-highlighter/scip-ctags bazel-bin/docker-images/syntax-highlighter/scip-ctags: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.0.0, with debug_info, not stripped ``` ## Test plan Tested for sourcegraph/scip-ctags image: ``` / $ strings scip-ctags | grep "Could not parse file" / $ echo $? 1 ```
sourcegraph-release-bot
pushed a commit
to sourcegraph/sourcegraph-public-snapshot
that referenced
this issue
Apr 19, 2024
Our rust binaries (e.g. scip-ctags/syntect_server) were being built in some mix of opt & fastbuild mode[1]. Unlike with Go where there is no release/debug mode flag, Rust requires opting into optimized release builds. We can do that automagically when building any oci_image target with the power of ✨ transitions ✨ This has the side-effect of our Go binaries no longer being stripped & containing debug symbols, see bazel-contrib/rules_go#3917 Also to note, [in Cargo.toml we opt into debug symbols in release mode](https://sourcegraph.com/github.com/sourcegraph/sourcegraph@nsc/bazel-release-mode-rust/-/blob/docker-images/syntax-highlighter/Cargo.toml?L67%3A11-70%3A9). Is this preserved by this PR for bazel[2]? [1] `strings` on the binaries showed the 3rd-party crates having `k8-opt` filepath names e.g. ``` $ / # strings syntect_server | grep k8- /tmp/bazel-working-directory/__main__/bazel-out/k8-opt-exec-ST-13d3ddad9198/bin/external/crate_index__onig_sys-69.8.1/onig_sys_build_script_.runfiles/crate_index__onig_sys-69.8.1 ``` but the final binaries (and the 1st-party crates) themselves were being built in fastbuild mode. See https://github.com/sourcegraph/devx-support/issues/790 for original point of contact [2] It seems like it may be preserved, but I dont know how reliable this is for Rust binaries ``` $ file bazel-bin/docker-images/syntax-highlighter/scip-ctags bazel-bin/docker-images/syntax-highlighter/scip-ctags: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.0.0, with debug_info, not stripped ``` ## Test plan Tested for sourcegraph/scip-ctags image: ``` / $ strings scip-ctags | grep "Could not parse file" / $ echo $? 1 ``` (cherry picked from commit ce6a366)
BolajiOlajide
pushed a commit
to sourcegraph/sourcegraph-public-snapshot
that referenced
this issue
Apr 22, 2024
…or Rust (#62049) bazel: transition oci_image to opt/release mode for Rust (#61740) Our rust binaries (e.g. scip-ctags/syntect_server) were being built in some mix of opt & fastbuild mode[1]. Unlike with Go where there is no release/debug mode flag, Rust requires opting into optimized release builds. We can do that automagically when building any oci_image target with the power of ✨ transitions ✨ This has the side-effect of our Go binaries no longer being stripped & containing debug symbols, see bazel-contrib/rules_go#3917 Also to note, [in Cargo.toml we opt into debug symbols in release mode](https://sourcegraph.com/github.com/sourcegraph/sourcegraph@nsc/bazel-release-mode-rust/-/blob/docker-images/syntax-highlighter/Cargo.toml?L67%3A11-70%3A9). Is this preserved by this PR for bazel[2]? [1] `strings` on the binaries showed the 3rd-party crates having `k8-opt` filepath names e.g. ``` $ / # strings syntect_server | grep k8- /tmp/bazel-working-directory/__main__/bazel-out/k8-opt-exec-ST-13d3ddad9198/bin/external/crate_index__onig_sys-69.8.1/onig_sys_build_script_.runfiles/crate_index__onig_sys-69.8.1 ``` but the final binaries (and the 1st-party crates) themselves were being built in fastbuild mode. See https://github.com/sourcegraph/devx-support/issues/790 for original point of contact [2] It seems like it may be preserved, but I dont know how reliable this is for Rust binaries ``` $ file bazel-bin/docker-images/syntax-highlighter/scip-ctags bazel-bin/docker-images/syntax-highlighter/scip-ctags: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.0.0, with debug_info, not stripped ``` ## Test plan Tested for sourcegraph/scip-ctags image: ``` / $ strings scip-ctags | grep "Could not parse file" / $ echo $? 1 ``` (cherry picked from commit ce6a366) Co-authored-by: Noah S-C <noah@sourcegraph.com>
|
The current behavior was actually last modified by me in #3527 I looked into Bazel's documented behavior for https://bazel.build/docs/user-manual#strip To the best of my understanding, this works as intended. |
|
I think you're right, Im not sure why I thought otherwise anymore 🥴 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What version of rules_go are you using?
0.46.0
What version of gazelle are you using?
0.35.0
What version of Bazel are you using?
7.1.0
Does this issue reproduce with the latest releases of all the above?
yes
What operating system and processor architecture are you using?
x86_64 linux (also tested on macOS)
Any other potentially useful information about your toolchain?
https://github.com/uber/hermetic_cc_toolchain on linux, presumably host toolchain on maOS
What did you do?
bazel build --compilation_mode={fastbuild,dbg,opt} //some/go_binary:targetWhat did you expect to see?
Setting
--compilation_mode=optresults in a stripped binary without debug info. The current behaviour may be WIA, in which case this issue can probably be closed.See Bazel slack thread for some discussion https://bazelbuild.slack.com/archives/CDBP88Z0D/p1712748379078069
What did you see instead?
The text was updated successfully, but these errors were encountered: