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

Only with all or split-debuginfo can -Zremap-path-scope remap SO symbols on macOS #117652

Open
weihanglo opened this issue Nov 7, 2023 · 4 comments
Open

Only with all or split-debuginfo can -Zremap-path-scope remap SO symbols on macOS #117652

weihanglo opened this issue Nov 7, 2023 · 4 comments
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) C-bug Category: This is a bug. F-trim-paths Feature: trim-paths O-macos Operating system: macOS

Comments

@weihanglo
Copy link
Member

Problem

It's very clear in RFC that

  • Remaps for split-debuginfo only happen in split debuginfo files.
  • Remaps for unsplit-debuginfo only happen in compiled executables or libraries.
  • Remaps for split-debuginfo-path only remap paths pointing to split debuginfo files.

However, on macOS even you have split debuginfo, SO symbols is still there in the executable.

# Neither `SCOPE=unsplit-debuginfo` or `SCOPE=object` work.
rustc main.rs -g -C -Zunstable-options split-debuginfo=packed \
    -Zremap-path-scope="${SCOPE}" \
    --remap-path-prefix="${HOME}"=

rm -rf main.dSYM # we don't need this

dsymutil -s main | rg N_SO # You'll see absolute paths to `main.rs`

Although it seems like expected as scope object is a union of unsplit-debuginfo | split-debuginfo-path | macro. However, since absolute paths are still embedded in executables, the doc lies on "This ensures all paths in compiled executables or libraries are remapped.

rustc --version --verbose

rustc 1.75.0-nightly (189d6c71f 2023-11-06)
binary: rustc
commit-hash: 189d6c71f3bb6c52113b5639a80839791974fd22
commit-date: 2023-11-06
host: aarch64-apple-darwin
release: 1.75.0-nightly
LLVM version: 17.0.4
@weihanglo weihanglo added C-bug Category: This is a bug. F-trim-paths Feature: trim-paths labels Nov 7, 2023
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Nov 7, 2023
@weihanglo weihanglo changed the title Only with all or split-debuginfo can -Zremap-path-scope remap SO symbols Only with all or split-debuginfo can -Zremap-path-scope remap SO symbols Nov 7, 2023
@weihanglo weihanglo changed the title Only with all or split-debuginfo can -Zremap-path-scope remap SO symbols Only with all or split-debuginfo can -Zremap-path-scope remap SO symbols on macOS Nov 7, 2023
@saethlin saethlin removed the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Nov 7, 2023
@weihanglo
Copy link
Member Author

One of the goal of -Ztrim-paths is described in RFC 3127:

cargo build with the default release profile should not produce any host filesystem dependent paths into binary executable or library. But it will retain the paths inside separate debug symbols file, if one exists, to help debuggers and profilers locate the source files.

On macOS, SO (and OSO) symbols need to be removed to achieve the original goal.

@Urgau
Copy link
Member

Urgau commented Nov 11, 2023 •
edited
Loading

The issue here is that we currently decide if we should remap paths for the entire compilation unit. [1]

This is because I don't think rustc can generate in the same invocation different path for the executable and debuginfo files as we can only give one at a time to LLVM.

EDIT: While what I said is true, it has nothing to do with the current issue about SO symbols on macOS. We are apparently just missing some linker args.

@bjorn3
Copy link
Member

bjorn3 commented Nov 11, 2023

The OSO symbols are created by the linker. You need to tell the linker to make them relative (Xcode 11+ only) and then dsymutil about the remapping for it to find the original object files. Or you need to rewrite the executable produced by the linker. See also #116948 (comment)

@weihanglo weihanglo mentioned this issue Dec 1, 2023
Closed
@weihanglo weihanglo added A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) O-macos Operating system: macOS labels Dec 1, 2023
@weihanglo weihanglo mentioned this issue Dec 5, 2023
Merged
bors added a commit to rust-lang-ci/rust that referenced this issue Dec 8, 2023
@bors
Auto merge of rust-lang#118518 - weihanglo:trim-paths-macos, r=<try>
4311f2e 
fix(trim-paths): trim `SO` and `DW_AT_comp_dir` symbols for root DI node

This is one way to fix <rust-lang#117652>.

## The issue

When `--remap-path-scope=object` is specified, user expect that there is
no local path embedded in final executables. Under `object` scope, the
current implementation only remap debug symbols if debug info is
splitted into its own file. In other words, when
`split-debuginfo=packed|unpacked` is set, rustc assumes there is no
embedded path in the final executable needing to be remapped.

However, this doesn't work.

* On Linux, the root `DW_AT_comp_dir` of a compile unit seems to go into the binary executables.
* On macOS, `SO` symbols are embedded in binary executables and libraries regardless a split-debuginfo file is built. Each `SO` symbol contains a path to the root source file of a debug info compile unit.

## The approach

Path of working directory in the root DI node seems to be embedded in
executables. Hence, we trim them when the scope of `unsplit-debuginfo`
is present, as if it is kinda a "unsplit" debuginfo.

## Unresolved issue

* Not sure where to add more test to consolidate it.
* Haven't investigate if we should apply the same logic to cranelift [here](https://github.com/rust-lang/rust/blob/64d7e0d0b61c460fbc882ae37c0f236756dd9c39/compiler/rustc_codegen_cranelift/src/debuginfo/mod.rs#L68-L80).
* Not sure if there is any other consequence doing this, but AFAIK debugging still works on macOS and Linux  with `profile.dev.trim-paths="object"` fairly (with some extra tweaks in cargo).
@weihanglo
Copy link
Member Author

Found on Linux DW_AT_comp_dir won't be remapped with scope object.

$ rustc -g main.rs \
  -C split-debuginfo=packed \
  -Zremap-path-scope=object \
  --remap-path-prefix="/absolute/path"
$ readelf -wi main | rg 'dwo'
   <10>   DW_AT_comp_dir    : (indirect string, offset: 0x0): /absolute/path/to/working/dir

A fix is also present in #118518 together as well.

bors added a commit to rust-lang-ci/rust that referenced this issue Jan 12, 2024
@bors
Auto merge of rust-lang#118518 - weihanglo:trim-paths-macos, r=<try>
d2d2599 
fix(trim-paths): trim `SO` and `DW_AT_comp_dir` symbols for root DI node

This is one way to fix <rust-lang#117652>.

## The issue

When `--remap-path-scope=object` is specified, user expect that there is
no local path embedded in final executables. Under `object` scope, the
current implementation only remap debug symbols if debug info is
splitted into its own file. In other words, when
`split-debuginfo=packed|unpacked` is set, rustc assumes there is no
embedded path in the final executable needing to be remapped.

However, this doesn't work.

* On Linux, the root `DW_AT_comp_dir` of a compile unit seems to go into the binary executables.
* On macOS, `SO` symbols are embedded in binary executables and libraries regardless a split-debuginfo file is built. Each `SO` symbol contains a path to the root source file of a debug info compile unit.

## The approach

Path of working directory in the root DI node seems to be embedded in
executables. Hence, we trim them when the scope of `unsplit-debuginfo`
is present, as if it is kinda a "unsplit" debuginfo.

## Unresolved issue

* Not sure where to add more test to consolidate it.
* Haven't investigate if we should apply the same logic to cranelift [here](https://github.com/rust-lang/rust/blob/64d7e0d0b61c460fbc882ae37c0f236756dd9c39/compiler/rustc_codegen_cranelift/src/debuginfo/mod.rs#L68-L80).
* Not sure if there is any other consequence doing this, but AFAIK debugging still works on macOS and Linux  with `profile.dev.trim-paths="object"` fairly (with some extra tweaks in cargo).
* This might be related?
    from <https://github.com/llvm/llvm-project/blob/847d8457d16a7334ba39bdd35c70faa1b295304d/clang/lib/CodeGen/CGDebugInfo.cpp#L623-L631>
    ```
    The DIFile used by the CU is distinct from the main source
    file. Its directory part specifies what becomes the
    DW_AT_comp_dir (the compilation directory), even if the source
    file was specified with an absolute path.
    ```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) C-bug Category: This is a bug. F-trim-paths Feature: trim-paths O-macos Operating system: macOS
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix(trim-paths): trim SO and DW_AT_comp_dir symbols for root DI node weihanglo/rust
5 participants
@Urgau @saethlin @weihanglo @bjorn3 @rustbot