From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) by sourceware.org (Postfix) with ESMTPS id CEF0E3858C2F for ; Mon, 15 Aug 2022 11:13:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CEF0E3858C2F Received: by mail-wm1-x32d.google.com with SMTP id c187-20020a1c35c4000000b003a30d88fe8eso7670782wma.2 for ; Mon, 15 Aug 2022 04:13:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:content-transfer-encoding:date:cc:to:from :subject:message-id:x-gm-message-state:from:to:cc; bh=nFZf3iS9A7sw8wAWmZ51C9w+k4H8VZhZTzvI0/p/T38=; b=5Y5SvVwus6G0EyleGRK8OsanOPlsG/JPBBozC3BPfd+dnMUe33jV9tM2cq8WEBwTIt 5hy5zTf5QSwmV49tLcDmybuAUSvlRfhJ1Va3Lj+4bHaQ6gjhOZw4YRSeF4NDErw490CQ jqPj7i27gKWVtlMTYz4x4PelQcklwFT37rlX//6sdVGI0rB4QTJD3ZIe4VudCJ+XCMIu DoPBRm5wRJ7nIYOTzKEVoBFPrrWON95oogDKmZEtPq2VwLxCdKZOOLEUJVwFD8YUksdj OIhX4erZPhUYJc0Ye4VFNnTXMHgfNKoxFx+CGDgaDn16VM+SvNhsQMFgdU33EW4Mz52q bp7w== X-Gm-Message-State: ACgBeo1UIKbApb5XKtz3Mxc7gdm4X8oyGVQA/2TVaLcOc9iXrLn486QP yWNOXXN5Nj6n3m5g5y/4qFmu1lhhVGF8JQ== X-Google-Smtp-Source: AA6agR6LND/WQ7iiyFVN/79Sv2bvrvVsWwUoH9K/C1tuCJU37rR2TlfEVqLn/xzs25mfvhTHTDuh3Q== X-Received: by 2002:a7b:c8d3:0:b0:3a6:2e:d4a8 with SMTP id f19-20020a7bc8d3000000b003a6002ed4a8mr918768wml.135.1660562009270; Mon, 15 Aug 2022 04:13:29 -0700 (PDT) Received: from ?IPv6:2001:8b0:aba:5f3c:27d9:5f4a:b4:2f81? ([2001:8b0:aba:5f3c:27d9:5f4a:b4:2f81]) by smtp.gmail.com with ESMTPSA id n37-20020a05600c502500b003a501ad8648sm9209024wmr.40.2022.08.15.04.13.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Aug 2022 04:13:28 -0700 (PDT) Message-ID: <1c0ab23fd0cc1bc34a229287529963526141327a.camel@linuxfoundation.org> Subject: Reproducible builds - supporting relative paths in *-prefix-map From: Richard Purdie To: gcc@gcc.gnu.org Cc: Khem Raj Date: Mon, 15 Aug 2022 12:13:28 +0100 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.1-0ubuntu1 MIME-Version: 1.0 X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham 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: Mon, 15 Aug 2022 11:13:33 -0000 Hi, I'm wondering if we'd be able to improve path handling in the -f*- prefix-map compiler options to cover relative paths? Currently it works well for absolute paths but if a file uses a relative path or a path with a symlink in, or a non-absolute path, it will miss those cases. For relative paths in particular it is problematic as you can't easily construct a compiler commandline that would cover all relative path options. At first glance this is relatively straight forward, for example: Index: gcc-12.1.0/gcc/file-prefix-map.cc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- gcc-12.1.0.orig/gcc/file-prefix-map.cc +++ gcc-12.1.0/gcc/file-prefix-map.cc @@ -70,19 +70,25 @@ remap_filename (file_prefix_map *maps, c file_prefix_map *map; char *s; const char *name; + char *realname; size_t name_len; =20 + realname =3D lrealpath (filename); + for (map =3D maps; map; map =3D map->next) - if (filename_ncmp (filename, map->old_prefix, map->old_len) =3D=3D 0) + if (filename_ncmp (realname, map->old_prefix, map->old_len) =3D=3D 0) break; - if (!map) + if (!map) { + free (realname); return filename; - name =3D filename + map->old_len; + } + name =3D realname + map->old_len; name_len =3D strlen (name) + 1; =20 s =3D (char *) ggc_alloc_atomic (name_len + map->new_len); memcpy (s, map->new_prefix, map->new_len); memcpy (s + map->new_len, name, name_len); + free (realname); return s; } =20 which address a realpath() call into the prefix mapping code.=C2=A0I did experiment with this and found it breaks compiling ruby and xen-tools which both have code which does: #include __FILE__ It may be possible to make the remapping conditional of not being directly in a #include statement but I didn't find the gcc code responsible for that as yet. I also noticed some valgrind tests fails after it, I've not looked into why that would be yet. I wanted to ask if there would be any interest in adding support for something like this? I suspect the include/__FILE__ issue is probably a latent bug anyway. If anyone has any pointers to the code I could improve my patch with I'm also happy to have them! In case it helps, my background on what I'm working on and why we'd find this useful follows:=C2=A0 I work on Yocto Project which cross compiles complete software stacks, we use gcc heavily and the resulting builds are all around us. We care deeply about build reproducibility. With autotools, we long ago realised that we were best off separating the source and the build output where we could and to do it we used relative paths, which removed a lot of problematic hardcoded paths in our output. More recently we've been using -fdebug-prefix-map and -fmacro-prefix- map (we need both since some of binutils doesn't seem to support the combined version yet). We use the debug information (split separately) to support on target debugging but where relative paths were used, we miss information as the remapping either doesn't happen correctly or is mangled. We'd like to fix our debug output but we're finding that hard without relative path support for *prefix-map. Cheers, Richard