lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c49cc967294f9a3a4a34f69b6a8727a6d3959ed8.camel@decadent.org.uk>
Date: Tue, 11 Mar 2025 18:36:25 +0100
From: Ben Hutchings <ben@...adent.org.uk>
To: Masahiro Yamada <masahiroy@...nel.org>, Miguel Ojeda
	 <miguel.ojeda.sandonis@...il.com>
Cc: Thomas Weißschuh <linux@...ssschuh.net>, Nathan
 Chancellor <nathan@...nel.org>, Nicolas Schier <nicolas@...sle.eu>, Miguel
 Ojeda <ojeda@...nel.org>,  Alex Gaynor <alex.gaynor@...il.com>, Boqun Feng
 <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
 Björn Roy Baron	 <bjorn3_gh@...tonmail.com>, Benno
 Lossin <benno.lossin@...ton.me>, Andreas Hindborg <a.hindborg@...nel.org>,
 Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>, 
 Danilo Krummrich	 <dakr@...nel.org>, linux-kbuild@...r.kernel.org,
 linux-kernel@...r.kernel.org, 	rust-for-linux@...r.kernel.org, Urgau
 <urgau@...ericable.fr>
Subject: Re: [PATCH] kbuild, rust: use -fremap-path-prefix to make paths
 relative

On Tue, 2025-03-11 at 20:03 +0900, Masahiro Yamada wrote:
> On Mon, Feb 17, 2025 at 10:23 PM Miguel Ojeda
> <miguel.ojeda.sandonis@...il.com> wrote:
> > 
> > On Mon, Feb 10, 2025 at 6:11 PM Thomas Weißschuh <linux@...ssschuh.net> wrote:
> > > 
> > > Remap source path prefixes in all output, including compiler
> > > diagnostics, debug information, macro expansions, etc.
> > 
> > Hmm... We don't do all the cases in the C side -- the docs ask to use
> > `KCFLAGS` when one wants to remove them in the debug info:
> > 
> >     https://docs.kernel.org/kbuild/reproducible-builds.html#absolute-filenames
> > 
> > I am not sure if there is a reason not to cover all cases in C (Cc'ing Ben).

I think we should use the prefix-map options by default, for both C and
Rust code.

The default of using absolute filenames only works when the build and
debug systems have their sources in the same absolute directory.  For
some developers this will always be true because they're the same
system.  In the general case, and particularly in production, it's
unlikely to be true.  See below.

> GCC manual mentions the below about the -fdebug-prefix-map=old=new
> 
> 
> "It can also be used to change an absolute path to
> a relative path by using . for new.
> This can give more reproducible builds, which are location
> independent, but may require an extra command to tell GDB
> where to find the source files."
> 
> 
> I guess "the extra command" might be a bit annoying.

The command in question is "dir <source-root-directory>".  It's not
particulary annoying.  It also isn't needed when invoking gdb with the
kernel source root as its current directory.

Running that command adds the directory to gdb's source search path,
causing it to look for sources referenced in debug info by:

1. Appending the full filename to that directory
2. Appending the base filename to that directory

(This is slightly simplified from the docuemntation at:
<https://sourceware.org/gdb/current/onlinedocs/gdb.html/Source-Path.html#Source-Path>.)

When the debug info has relative filenames, case 1 should always work.

When the debug info has absolute filenames, case 2 can work if all
sources are in the same directory.  But the kernel has source files
spread across many directories, so there's no general way to make gdb
find them all.

Ben.

-- 
Ben Hutchings
A free society is one where it is safe to be unpopular.
                                                      - Adlai Stevenson

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ