From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) by sourceware.org (Postfix) with ESMTPS id 7EF903858404 for ; Mon, 15 Aug 2022 14:37:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7EF903858404 Received: by mail-ed1-x530.google.com with SMTP id s11so9797047edd.13 for ; Mon, 15 Aug 2022 07:37:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=ysNSyiHhVuLDVKV/B3/KxaDIxhIyjTNB78vOLXgRzcU=; b=e92yrc0Gr7Iqvp8SXCjtPbsvfTIcjTvNb3k9aycs/unpWvdjE3/23L+ACoubUfRchk 6FWuW+vYBsqpeiNzuanIcgXeg4fYoPteXpDRvTYsX6ZpTei+fyk+b6j0lom2cjSiK80c 7XWdfWVO4uZ1U98rfZIITJ/s7G7KZwFB9HBmlxparDfCqOgjFrYlwWjCvxbZswhBZxKF 38oDtAlO2Tlcao+fCDgK3RnUhs0vbNJ5dSgIO8zY+oHowGcTzEy0yD/r0RY4tG26ACT9 r6Xln7g6P54++6CqgNYLeagbLnIJItC+mFRq2WXBAB2x126N6OdRBTMyRc6MDCo7CoKH rwWg== X-Gm-Message-State: ACgBeo0EcWC85OUyi0g2xDXS6ULc7sThzcl+v+VsIUiI6xFLyc/FTMtt XStWnMzp/bWPjLgi9aPc0O5TOuinxw7Owpmq38M= X-Google-Smtp-Source: AA6agR4ZZPJ+mGQcH01DFdS3h/twDhdifV1cGwo9huRimzUACO4yjgIVziwTrq2l3JwUSUvqfCEtDbqanC4xWJXrJNY= X-Received: by 2002:a05:6402:d5d:b0:441:c3f8:cf96 with SMTP id ec29-20020a0564020d5d00b00441c3f8cf96mr14783474edb.238.1660574259054; Mon, 15 Aug 2022 07:37:39 -0700 (PDT) MIME-Version: 1.0 References: <1c0ab23fd0cc1bc34a229287529963526141327a.camel@linuxfoundation.org> In-Reply-To: From: David Edelsohn Date: Mon, 15 Aug 2022 10:36:13 -0400 Message-ID: Subject: Re: Reproducible builds - supporting relative paths in *-prefix-map To: Richard Purdie Cc: GCC Development , Khem Raj Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_ASCII_DIVIDERS, RCVD_IN_DNSWL_NONE, 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: Mon, 15 Aug 2022 14:37:42 -0000 On Mon, Aug 15, 2022 at 10:28 AM Richard Purdie via Gcc wrote: > > On Mon, 2022-08-15 at 12:13 +0100, Richard Purdie via Gcc wrote: > > 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 > > =================================================================== > > --- 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; > > > > + realname = lrealpath (filename); > > + > > for (map = maps; map; map = map->next) > > - if (filename_ncmp (filename, map->old_prefix, map->old_len) == 0) > > + if (filename_ncmp (realname, map->old_prefix, map->old_len) == 0) > > break; > > - if (!map) > > + if (!map) { > > + free (realname); > > return filename; > > - name = filename + map->old_len; > > + } > > + name = realname + map->old_len; > > name_len = strlen (name) + 1; > > > > s = (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; > > } > > > > which address a realpath() call into the prefix mapping code. I 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! > > To answer my own question, something like: > > +Index: gcc-12.1.0/libcpp/macro.cc > +=================================================================== > +--- gcc-12.1.0.orig/libcpp/macro.cc > ++++ gcc-12.1.0/libcpp/macro.cc > +@@ -563,7 +563,7 @@ _cpp_builtin_macro_text (cpp_reader *pfi > + if (!name) > + abort (); > + } > +- if (pfile->cb.remap_filename) > ++ if (pfile->cb.remap_filename && !pfile->state.in_directive) > + name = pfile->cb.remap_filename (name); > + len = strlen (name); > + buf = _cpp_unaligned_alloc (pfile, len * 2 + 3); > > seems to do roughly what I was wondering about. > > I'd be interested to understand whether some patch along the lines I've > mentioned here would stand a chance of being accepted or not. Thanks for recognizing this issue and proposing a solution. It's probably more effective to submit this as an actual patch to gcc-patches and cc David Malcolm, libcpp maintainer, than to ask hypotheticals on the GCC mailing list. Thanks, David