From: Gary Guo <gary@garyguo.net>

When building with a out directory (O=), absolute paths can end up in the
file name in `#[track_caller]` or the panic message. This is not desirable
as this leaks the exact path being used to build the kernel into the binary
which is not very helpful to achieve reproducibility. It also means that
the same location can appear in two forms (relative or absolute).

This is reported by Asahi [1] and is being workaround in [2] previously to
force everything to be absolute path. Using absolute path for everything
sovles the inconsistency, however it does not address the reproducibility
issue. So, fix this by remap all absolute paths to srctree to relative path
instead.

This change can be validated by building a kernel with O=, strip debug info
on vmlinux, and then check if the absolute path exists in `strings vmlinux`,
e.g. `strings vmlinux |grep \/home`.

Reported-by: Janne Grunau <j@jannau.net>
Reported-by: Asahi Lina <lina+kernel@asahilina.net>
Closes: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/Per-call-site.20data.20and.20lock.20class.20keys/near/572466559 [1]
Link: https://github.com/AsahiLinux/linux/commit/54ab88878869036c9d6620101bfe17a81e88c2f9 [2]
Signed-off-by: Gary Guo <gary@garyguo.net>
---
 rust/Makefile          | 1 +
 scripts/Makefile.build | 1 +
 2 files changed, 2 insertions(+)

diff --git a/rust/Makefile b/rust/Makefile
index 629b3bdd2b20..598d2efede32 100644
--- a/rust/Makefile
+++ b/rust/Makefile
@@ -582,6 +582,7 @@ quiet_cmd_rustc_library = $(if $(skip_clippy),RUSTC,$(RUSTC_OR_CLIPPY_QUIET)) L
 		--crate-type rlib -L$(objtree)/$(obj) \
 		--crate-name $(patsubst %.o,%,$(notdir $@)) $< \
 		--sysroot=/dev/null \
+		--remap-path-prefix=$(abspath $(srctree))= \
 		-Zunstable-options \
 	$(if $(rustc_objcopy),;$(OBJCOPY) $(rustc_objcopy) $@) \
 	$(cmd_objtool)
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 204e58dd1bb0..03dde30e953c 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -333,6 +333,7 @@ rust_common_cmd = \
 	--crate-type rlib -L $(objtree)/rust/ \
 	--crate-name $(basename $(notdir $@)) \
 	--sysroot=/dev/null \
+	--remap-path-prefix=$(abspath $(srctree))= \
 	--out-dir $(dir $@) --emit=dep-info=$(depfile)
 
 # `--emit=obj`, `--emit=asm` and `--emit=llvm-ir` imply a single codegen unit

base-commit: 36896083ef4dbc302e406f01975a227784160cf8
-- 
2.51.2

On Sat, Feb 7, 2026 at 3:44 PM Gary Guo <gary@kernel.org> wrote:
>
> So, fix this by remap all absolute paths to srctree to relative path
> instead.

In case it matters to Kbuild, we had a relatively recent revert
related to this flag:

  dbdffaf50ff9 ("kbuild, rust: use -fremap-path-prefix to make paths relative")
  8cf5b3f83614 ("Revert "kbuild, rust: use -fremap-path-prefix to make
paths relative"")

  https://lore.kernel.org/rust-for-linux/20250511-kbuild-revert-file-prefix-map-v1-0-9ba640c8411e@weissschuh.net/

From what I see in the thread (but I didn't get a confirmation back
then), the issue was some developers relying on invoking the debugger
in a different working directory than the `srctree`.

Thanks Gary!

Cheers,
Miguel

On Sat Feb 7, 2026 at 3:22 PM GMT, Miguel Ojeda wrote:
> On Sat, Feb 7, 2026 at 3:44 PM Gary Guo <gary@kernel.org> wrote:
>>
>> So, fix this by remap all absolute paths to srctree to relative path
>> instead.
>
> In case it matters to Kbuild, we had a relatively recent revert
> related to this flag:
>
>   dbdffaf50ff9 ("kbuild, rust: use -fremap-path-prefix to make paths relative")
>   8cf5b3f83614 ("Revert "kbuild, rust: use -fremap-path-prefix to make
> paths relative"")
>
>   https://lore.kernel.org/rust-for-linux/20250511-kbuild-revert-file-prefix-map-v1-0-9ba640c8411e@weissschuh.net/

Ah, that explains why I recall we had this flag in Kbuild but can only find the
filter-out directives now. I missed the revert email.

I am not convinced that the ability to launch debugger outside source
directory overweights the benefit of not leaking absolute paths and making
builds reproducible.

The reverting cover letter says "As there is no simple or uniform way to
specify the source directory explicitly" which is clearly not the case as you
can just invoke the debugger in a different working directory... GDB also
provides a way to provide source directory search path:
https://sourceware.org/gdb/current/onlinedocs/gdb.html/Source-Path.html.
Similarly, LLDB provides `settings set target.source-map`:
https://lldb.llvm.org/use/map.html#remap-source-file-pathnames-for-the-debug-session

I think we should revert the revert, then.

Best,
Gary

>
> From what I see in the thread (but I didn't get a confirmation back
> then), the issue was some developers relying on invoking the debugger
> in a different working directory than the `srctree`.
>
> Thanks Gary!
>
> Cheers,
> Miguel