Support different paths remapping for different scopes

[Urgau]

I want to raise that I think it should be possible to apply different remapping to the same path for different scopes. It seems like remap-path-prefix was too generic in remapping across many different use cases, and now the scope argument is being introduced to limit the scope, but that doesn't deal with the situation where you want to remap the same path differently across scopes.

E.g. imagine I want to remap /home/cameron/code/project to "." for macro, but to "" for split-debuginfo. This would be necessary on macOS, where OSO stabs cannot use relative paths (see #132143).

You could imagine doing something like:

rustc ...
  --remap-path-scope=split-debuginfo \
  --remap-path-prefix=/home/cameron/code/project=. \
  --remap-path-scope=macro \
  --remap-path-prefix=/home/cameron/code/project=

But repeated usage of these flags are independently aggregated, rather than ordered, so that wouldn't work.

Not sure on the right design here, but I do think being able to express ^ is worthwhile.

Originally posted by @csmulhern in #111540

[Urgau]

@csmulhern All debuginfo scopes have been remapped to a unique debuginfo scope in #122450

[csmulhern]

@Urgau, thanks!

I've updated the example code in #122450 to use debuginfo instead of split-debuginfo, if you want to do the same here. Thanks for filing this. Small correction on the title: the ask would be to support different remapping for different scopes within --remap-path-prefix. There's no clear need (at least in my mind) for different path remapping inside the same scope (which I guess would imply that the scopes aren't fine grained enough).

[Urgau]

Small correction on the title: the ask would be to support different remapping for different scopes within --remap-path-prefix

Fixed.

E.g. imagine I want to remap /home/cameron/code/project to "." for macro, but to "" for debuginfo. This would be necessary on macOS, where OSO stabs cannot use relative paths (see #132143).

The OSO issue seems better served with Apple's linker option -oso_prefix, "which can be used to relativise the OSO paths"¹, instead of allowing different remap paths with different scopes.

Footnotes

1. https://milen.me/writings/apple-linker-ld64-deterministic-builds-oso-prefix/#linker ↩

[csmulhern]

Small correction on the title: the ask would be to support different remapping for different scopes within --remap-path-prefix

Fixed.

Cheers!

E.g. imagine I want to remap /home/cameron/code/project to "." for macro, but to "" for debuginfo. This would be necessary on macOS, where OSO stabs cannot use relative paths (see #132143).

The OSO issue seems better served with Apple's linker option -oso_prefix, "which can be used to relativise the OSO paths"1, instead of allowing different remap paths with different scopes.

I agree that path replacement for DWARF debug info in macOS that is funneled through OSO stabs can be accomplished by using -Clink-args=-Wl,oso_prefix=..., but I don't think users of rustc should have to do that themselves. It seems like --remap-path-prefix should do that for the debuginfo scope.

This comment (#116948 (comment)) suggests the same. I.e. that this in the purview of --remap-path-prefix, but suggests maybe oso_prefix cannot be used because of the minimum version of macOS that rustc supports.

Users of rustc who do something like:

rustc --remap-path-scope=all --remap-path-prefix=/Users/user/path= ...

should reasonably expect that no traces of /Users/user/path remain in their binary / split debug info, and that would not be true on macOS if rustc cannot deal with remapping to relative paths within macOS because of how OSO stabs behave. rustc could either:

1. Automatically deal with this by forming absolute paths for remappings to relative paths within OSO stabs by e.g. rooting at ./ or /.

2. Throw an error if --remap-path-prefix with a relative path remapping is used on macOS when the remapping scope includes debuginfo.

3. Clearly document this failure mode in the documentation for --remap-path-prefix and / or log a warning if --remap-path-prefix with a relative path remapping is used on macOS when the remapping scope includes debuginfo.

4. Something else?

1 or 2 seem preferable to me.

Then regardless of the path chosen here, I was separately raising that it could be that maybe users would want to remap the same path differently across scopes (e.g. macro and debuginfo). The only example that's relevant to me is ^, so maybe there aren't any significant use cases here if ^ is resolved, but I can imagine there are other cases. In the case that is desirable, I think the current way --remap-path-prefix and --remap-path-scope interact / are independently aggregated would prevent being able to express that.

One way to express that would be having ordering matter for --remap-path-prefix and --remap-path-scope (like my example invocation in the original path).

Another way would be something like collapsing --remap-path-prefix and --remap-path-scope into individual parameters (e.g. --remap-path-prefix-macro and --remap-path-prefix-debuginfo`).

I'm sure there are other designs here too but I haven't thought too deeply about it.

[Urgau]

should reasonably expect that no traces of /Users/user/path remain in their binary

That's a reasonable assumption that is broken by reality. rustc doesn't control the inputs given to it (like staticlib with paths not remapped) or what the externals tools like linker do (or can do).

3. Clearly document this failure mode in the documentation for --remap-path-prefix

We are in the process of documenting that it's a best-effort, in particular regarding external tools like linker, #142372 (improvements welcome).

This comment (#116948 (comment)) suggests the same. I.e. that this in the purview of --remap-path-prefix, but suggests maybe oso_prefix cannot be used because of the minimum version of macOS that rustc supports.

Minimum version is not necessarely a issue, we can try with the -oso_prefix arg and if Apple's ld linker fails, fallback without it. Patch welcome.

[Urgau]

Then regardless of the path chosen here, I was separately raising that it could be that maybe users would want to remap the same path differently across scopes (e.g. macro and debuginfo). The only example that's relevant to me is ^, so maybe there aren't any significant use cases here if ^ is resolved, but I can imagine there are other cases

Supporting different paths for different scopes would quite a lot of complexity, which I have not yet seeing a compelling use-cases that can't be solve by some other way. I would love if you (or someone else) could come with an example that isn't a workaround for external tools.

Another way would be something like collapsing --remap-path-prefix and --remap-path-scope into individual parameters (e.g. --remap-path-prefix-macro and --remap-path-prefix-debuginfo`).

If we were do to it (which I'm not suggesting), the simplest way to be add the scopes as sort of "parameters" either at the start of end of the path, like so --remap-path-prefix /tmp=debuginfo:/virtual or --remap-path-prefix /tmp=/virtual:debuginfo (their could threrically have some ambiguity be they IMO extremely unlikely).

[csmulhern]

That's a reasonable assumption that is broken by reality. rustc doesn't control the inputs given to it (like staticlib with paths not remapped) or what the externals tools like linker do (or can do).

That's fair. I think in the case of relative paths and OSO stabs though this is broken at the object file level (which does seem in the purview of rustc?). The workaround is to tell rustc not to get involved, and then fix it up through the linker.

We are in the process of documenting that it's a best-effort, in particular regarding external tools like linker, #142372 (improvements welcome).

That's great, and I agree with the balance of responsibilities being implied there. Cheers.

Minimum version is not necessarely a issue, we can try with the -oso_prefix arg and if Apple's ld linker fails, fallback without it. Patch welcome.

That sort of approach SGTM. If it's best effort, then I don't see why we shouldn't use oso_prefix when available.

Supporting different paths for different scopes would quite a lot of complexity, which I have not yet seeing a compelling use-cases that can't be solve by some other way. I would love if you (or someone else) could come with an example that isn't a workaround for external tools.

Agreed that this is mostly bikeshedding for now around a potential API limitation rather than one with a concrete use case. Though in the macro and debuginfo example, my original example was based on preferring remapping to empty string to get nice relative paths from e.g. std::file in error logs, but needing to remap to e.g. "." on macOS for debuginfo to workaround the OSO stabs issue. This is really minor though, and could also be resolved by just unconditionally remapping to "." and accepting the slightly uglier error logs from macros.

If we were do to it (which I'm not suggesting), the simplest way to be add the scopes as sort of "parameters" either at the start of end of the path, like so --remap-path-prefix /tmp=debuginfo:/virtual or --remap-path-prefix /tmp=/virtual:debuginfo (their could threrically have some ambiguity be they IMO extremely unlikely).

Yup, that makes sense. You could even do it with the scope out in front. E.g.

---remap-path-prefix macro:/tmp=/virtual

should reasonably expect that no traces of /Users/user/path remain in their binary / split debug info, and that would not be true on macOS if rustc cannot deal with remapping to relative paths within macOS because of how OSO stabs behave.

Just to correct myself on this... I do think my suggestions around what users should reasonable expect are true, but actually after thinking about it again, with the OSO stab issue, those paths will still not be in their binary. The debuginfo will just be missing for anything containing the remapped path. So in that case, this does seem less like a concern from the point of accidentally leaking paths users expected to be remapped, and really more just that debuginfo is broken (and there is a workaround to fix it - remap to absolute paths).

We can probably use #132143 to track how we go about fixing the --remap-path-prefix to "" on macOS for debuginfo (maybe by attempting to use oso_prefix as a linker flag).

In terms of actually needing to support different remappings for different scopes, I'll leave that up to the Rust team to decide on the necessity, and you can feel free to close this issue if that's not a reasonable requirement.

Patch welcome.

I haven't contributed to rustc before, so if you have any high level guidance on where best to make these changes I'm not opposed to taking a look.

[Urgau]

I haven't contributed to rustc before, so if you have any high level guidance on where best to make these changes I'm not opposed to taking a look.

We have a development guide at rustc-dev-guide, it contains instructions for building and testing the compiler, and much more. Any compiler question is best asked in our #t-compiler/help Zulip channel.

Regarding the change it-self, I think we should introduce the -oso_prefix argument in the add_order_independent_options method (or a submethod of Linker)

rust/compiler/rustc_codegen_ssa/src/back/link.rs

Line 2445 in d51b6f9

fn add_order_independent_options(

with something like:

if sess.target.is_like_darwin && LinkerFlavor::Darwin(..) = flavor {
    // Default to emitting only the file name of the PDB file into
    // the binary instead of the full path. Emitting the full path
    // may leak private information.

    let mut basepath = out_filename.to_path_buf();
    basepath.set_file_name("");
    cmd.link_arg("-oso_prefix");
    cmd.link_arg(&basepath);
}

Then will need to remove it if it's not supported by the current linker, that's done in the linker_with_args in this loop (look at how it's done for the other ones)

rust/compiler/rustc_codegen_ssa/src/back/link.rs

Line 732 in d51b6f9

loop {

rust/compiler/rustc_codegen_ssa/src/back/link.rs

Lines 751 to 753 in d51b6f9

	&& unknown_arg_regex.is_match(&out)
	&& out.contains("-no-pie")
	&& cmd.get_args().iter().any(|e| e == "-no-pie")

At last we will need a test, given that it a bit of a niche, a tests/run-make test is probably advised, with help of llvm_nm and a bit of grep-like parsing to verify that OSO entries are indeed relative.