Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Setting --compilation_mode=opt results in a binary with debug info + symbol table not being stripped #3917

Closed
Strum355 opened this issue Apr 10, 2024 · 2 comments
Closed

Setting --compilation_mode=opt results in a binary with debug info + symbol table not being stripped #3917

Strum355 opened this issue Apr 10, 2024 · 2 comments

Comments

@Strum355
Copy link
Contributor

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:target

What did you expect to see?

Setting --compilation_mode=opt results 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?

batcheshelper.dbg:  ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.0.0, Go BuildID=redacted, with debug_info, not stripped
batcheshelper.fast: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.0.0, Go BuildID=redacted, stripped
batcheshelper.opt:  ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go BuildID=redacted, with debug_info, not stripped
@Strum355 Strum355 mentioned this issue Apr 12, 2024
Merged
Strum355 added a commit to sourcegraph/sourcegraph-public-snapshot that referenced this issue Apr 15, 2024
@Strum355
bazel: transition oci_image to opt/release mode for Rust (#61740)
ce6a366 
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
```
Merged
sourcegraph-release-bot pushed a commit to sourcegraph/sourcegraph-public-snapshot that referenced this issue Apr 19, 2024
@Strum355 @github-actions
bazel: transition oci_image to opt/release mode for Rust (#61740)
908f53c 
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
@sourcegraph-release-bot @Strum355
[Backport 5.3.9104] bazel: transition oci_image to opt/release mode f…
e2cf4ee 
…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 sourcegraph/devx-support#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>
@malt3
Copy link
Contributor

malt3 commented May 16, 2024 •
edited
Loading

The current behavior was actually last modified by me in #3527

I looked into Bazel's documented behavior for --strip. It says:

 --strip (always|never|sometimes)

This option determines whether Bazel will strip debugging information from all binaries and shared libraries, by invoking the linker with the -Wl,--strip-debug option.

--strip=always means always strip debugging information.
--strip=never means never strip debugging information.
The default value of --strip=sometimes means strip if the --compilation_mode is fastbuild.

https://bazel.build/docs/user-manual#strip

To the best of my understanding, this works as intended.

@Strum355
Copy link
Contributor Author

Strum355 commented Jun 4, 2024

I think you're right, Im not sure why I thought otherwise anymore 🥴

@Strum355 Strum355 closed this as completed Jun 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@malt3 @Strum355