From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id C816F3858D37 for ; Wed, 17 Aug 2022 17:00:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C816F3858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from reform (unknown [178.228.156.55]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 4D770300070C; Wed, 17 Aug 2022 19:00:55 +0200 (CEST) Received: by reform (Postfix, from userid 1000) id 714DB2E8157E; Wed, 17 Aug 2022 13:23:06 +0200 (CEST) Date: Wed, 17 Aug 2022 13:23:06 +0200 From: Mark Wielaard To: Richard Purdie Cc: gcc@gcc.gnu.org, Khem Raj , Sergio Durigan Junior Subject: Re: Reproducible builds - supporting relative paths in *-prefix-map Message-ID: References: <1c0ab23fd0cc1bc34a229287529963526141327a.camel@linuxfoundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00, DATE_IN_PAST_03_06, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2022 17:00:59 -0000 Hi Richard, On Mon, Aug 15, 2022 at 09:29:03PM +0100, Richard Purdie wrote: > On Mon, 2022-08-15 at 21:55 +0200, Mark Wielaard wrote: > > I might be misinterpreting the issue you are seeing. > > > > But one problem with debuginfo/DWARF is that relative source paths > > aren't clearly defined. If you move or install the executable or > > (split) debug file out of the build directory a DWARF reader has no > > way to know what the paths are relative to. > > > > So for DWARF the paths always have to be absolute (they can still be > > relative to the compilation dir (DW_AT_comp_dir), but at least that > > has to be absolute (and the compiler should turn any relative path > > into an absolute one or make sure they are relative to an absolute > > compilation directory path). > > It gets slightly more complicated as we build in a directory separate > to the source where we can. Some source files are generated source > files and placed in the build directory whilst many are in the source > directory. DW_AT_comp_dir can be set to one or the other but it is the > relative path between build and source which is problematic. Could you give an example directory structure when that creates a problem? Any debug paths generated should be absolute or relative to an absolute path. In particular the DW_AT_comp_dir is normally an absolute path (getpwd). So normally just remapping some prefix of the pwd (either srcdir and/or builddir) should work to keep the relative paths correct when moving the (generated) sources under that new absolute path. I am probably missing something about the directory setup that makes that reasoning invalid. > We split the debuginfo into a separate package. We also look at the > sources it references and those go into a different separate package > too. We support populating a remote debuginfod server with these or > installing them onto the target. Nice. How do you lookup the referenced sources and where are they then installed? > > Using known absolute paths generated with debugedit or > > -fdebug-prefix-map makes sure the paths used in the debuginfo/DWARF > > are always the same independent from the current srcdir or builddir to > > make them reproducible. And the user/tools don't have to guess what > > the relative paths are relative to. > > We have that working and set debug-prefix-map today. What is > problematic is trying to recreate the relative paths on target between > our source and build directories. Currently, most generated files in > the build directory just don't get handled correctly on target. We'd > like to fix that. There is currently no way to remap a relative path > though, at least as far as I could determine. So is the problem that when collecting the generated source files you cannot map the debug-prefix-map back anymore? The relative paths are relative to the original (absolute) prefix, but you only have the remapped prefix? Cheers, Mark