Message ID | 20220817121534.1825108-1-richard.purdie@linuxfoundation.org |
---|---|
State | New, archived |
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:6a10:38f:b0:2d5:3c95:9e21 with SMTP id 15csp2608741pxh; Wed, 17 Aug 2022 05:16:30 -0700 (PDT) X-Google-Smtp-Source: AA6agR7B7lxRiEv5n0ySdjkdN5U4I57Amu5+vhawBnRKbgMdUb1tfRzSswXnh2kz23sekwOpZrxd X-Received: by 2002:a17:906:9f2a:b0:730:bc30:da30 with SMTP id fy42-20020a1709069f2a00b00730bc30da30mr16711762ejc.763.1660738590055; Wed, 17 Aug 2022 05:16:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660738590; cv=none; d=google.com; s=arc-20160816; b=zg6HXFidrFirSM2bnRtkWmbp2Esnh+nmT4zbYimAdX4zWeIFyg2q4mnFKiQDJJa52B TLuMAf16Qlzy5TRiJq26EOfmET6ZmOUr1j6QjPGb3cnje57Qk2MsYG+Gs5TOpJpE5/Lx bOKX/7Sh6YIso5KRZLx1f4p7W/QKG8gwCwdXANhPWeWHIBQKNu6B/yYBE7sf1mIH/3eV eiZFVVxgX7Bk6oErFti9UqAw0r5dEWDH49r7N9YpwrTAHsR5UY+QkbpnvCburFS4uKlC feHzRq1iJ8CNu8Sr7tEHFKiE/eFDovXjIMEaDjn4ZDr6FS//HqELuytLepDwpLt05rQW NXWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:reply-to:from:list-subscribe:list-help:list-post :list-archive:list-unsubscribe:list-id:precedence :content-transfer-encoding:mime-version:message-id:date:subject:to :dmarc-filter:delivered-to:dkim-signature:dkim-filter; bh=S/+y2DXLgZ5EOZ4rOe6Ruqr3JnpS+IgHlFEZHIecLCg=; b=GbkgF7FvWiPAORHaNAkCXQ8N54llMz+8pV38HruiLPu3spPuOZOZ4RhZBOu1pIGFco N9fsgqglLL5+4CaDKgV1dedp80KZKo1DpFlta5HFMMmzzVBdWO4C1KHoGD8nmbAo/8bU fq3ZAdKLNPWIwaTYdI/8ozhf7Ha5QDsNhh9IxPJbnQ9faNRIUgW3ayywOr37CV92trX3 l5BhLmQJN6y1akrkaJGIuypnU4NMhX7ue4dnQybWjm2pj3YodhSSEcnuomo2AnDMAxrc VE0RLDnkwNbGi+U8wgPGSAVdaKQXXB++VWjB4H2MBabj97nRUBQGUHoS9KqTSGKhXmyD 1OYg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=pkQMCO4r; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id jo25-20020a170906f6d900b00730824744dasi472920ejb.507.2022.08.17.05.16.29 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Aug 2022 05:16:30 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=pkQMCO4r; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6EA6E3858014 for <ouuuleilei@gmail.com>; Wed, 17 Aug 2022 12:16:22 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6EA6E3858014 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1660738582; bh=S/+y2DXLgZ5EOZ4rOe6Ruqr3JnpS+IgHlFEZHIecLCg=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=pkQMCO4r9899tHlKQ/D4lqPZsdCJ3GQp6smR8IJTCI8LsLi91umyQL042UBa6slZu Gz9GDa+VxNxOilKSuugkRBy2xv9JB89VXSbNVnyd01+hJy/6ktls7IkTdUl0hCKM5z I61DIbhpB23IIIa9Xvnoru7G9ALKzPgRV77Z9hi0= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) by sourceware.org (Postfix) with ESMTPS id 6D9BD3858D37 for <gcc-patches@gcc.gnu.org>; Wed, 17 Aug 2022 12:15:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6D9BD3858D37 Received: by mail-wm1-x32b.google.com with SMTP id v7-20020a1cac07000000b003a6062a4f81so909211wme.1 for <gcc-patches@gcc.gnu.org>; Wed, 17 Aug 2022 05:15:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc; bh=S/+y2DXLgZ5EOZ4rOe6Ruqr3JnpS+IgHlFEZHIecLCg=; b=FCODqw35iOk4AHiLRBZMbrKnJQnCh+avIKaO9u9tlmLRR54VjldAj6sNy1hPOfYcCE eMgDIhGQ4K8a1lCNoRmoMfLfjbLHBmKmGbeP2xS0HtmBBsz9U1iZ97i+pZe4UOx2Ge9H TR0/v6Wy34ZSD5fvFWxNa++qp55aTIT7AHQ07kUE0BQS7Pm2ms0iAshnH0osm+z3RTJu H0TLpbAUR0n32ZAwg+P365zYtkLOE0O03lGbXz/0nPvixoUbJPK3voFFtL/AQ0IYATUJ 6r2LAA56ma83fnWhik05J6Vx0xQxW30vXWJu0ZoBC28hVytdzA3DocN8/Vo7QbInNqWF UZXQ== X-Gm-Message-State: ACgBeo0HJTvRhaTiEuvAgJij4DizW20oiW38mpLkDSJJ3AfeH36wMPhZ SLhfODqXwN6MOk5LfeDGZwqObeayZgXwYw== X-Received: by 2002:a05:600c:4e15:b0:3a6:152a:9143 with SMTP id b21-20020a05600c4e1500b003a6152a9143mr1688966wmq.20.1660738536381; Wed, 17 Aug 2022 05:15:36 -0700 (PDT) Received: from max.int.rpsys.net ([2001:8b0:aba:5f3c:3694:2ef4:2932:37d5]) by smtp.gmail.com with ESMTPSA id t126-20020a1c4684000000b003a5fe5ed7edsm2408220wma.0.2022.08.17.05.15.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Aug 2022 05:15:35 -0700 (PDT) To: gcc-patches@gcc.gnu.org Subject: [PATCH 1/2] gcc/file-prefix-map: Allow remapping of relative paths Date: Wed, 17 Aug 2022 13:15:33 +0100 Message-Id: <20220817121534.1825108-1-richard.purdie@linuxfoundation.org> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-11.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, 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-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Richard Purdie via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Richard Purdie <richard.purdie@linuxfoundation.org> Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1741410627582842705?= X-GMAIL-MSGID: =?utf-8?q?1741410627582842705?= |
Series |
[1/2] gcc/file-prefix-map: Allow remapping of relative paths
|
|
Commit Message
Richard Purdie
Aug. 17, 2022, 12:15 p.m. UTC
Relative paths currently aren't remapped by -ffile-prefix-map and friends.
When cross compiling with separate 'source' and 'build' directories, the same
relative paths between directories may not be available on target as compared
to build time.
In order to be able to remap these relative build paths to paths that would
work on target, resolve paths within the file-prefix-map function using
realpath().
This does cause a change of behaviour if users were previously relying upon
symlinks or absolute paths not being resolved.
Use basename to ensure plain filenames don't have paths added.
gcc/ChangeLog:
* file-prefix-map.cc (remap_filename): Allow remapping of relative paths
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
gcc/file-prefix-map.cc | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
Comments
On 8/17/22 06:15, Richard Purdie via Gcc-patches wrote: > Relative paths currently aren't remapped by -ffile-prefix-map and friends. > When cross compiling with separate 'source' and 'build' directories, the same > relative paths between directories may not be available on target as compared > to build time. > > In order to be able to remap these relative build paths to paths that would > work on target, resolve paths within the file-prefix-map function using > realpath(). Understood. > > This does cause a change of behaviour if users were previously relying upon > symlinks or absolute paths not being resolved. I'm not too worried about this scenario. > > Use basename to ensure plain filenames don't have paths added. > > gcc/ChangeLog: > > * file-prefix-map.cc (remap_filename): Allow remapping of relative paths Basically OK. Just formatting nit: > > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> > --- > gcc/file-prefix-map.cc | 15 ++++++++++++--- > 1 file changed, 12 insertions(+), 3 deletions(-) > > diff --git a/gcc/file-prefix-map.cc b/gcc/file-prefix-map.cc > index 24733f831d6..50d5d724a8f 100644 > --- a/gcc/file-prefix-map.cc > +++ b/gcc/file-prefix-map.cc > @@ -70,19 +70,28 @@ remap_filename (file_prefix_map *maps, const char *filename) > file_prefix_map *map; > char *s; > const char *name; > + char *realname; > size_t name_len; > > + if (lbasename (filename) == filename) > + return filename; > + > + 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; > + } Put the the curley braces go on their own lines, indented two positions. The code inside the curleys is indented two more positions. I fixed that and pushed this change to the trunk. THanks, jeff
> gcc/ChangeLog: > > * file-prefix-map.cc (remap_filename): Allow remapping of relative paths Small regression in Ada though, probably a missing guard somewhere: === gnat tests === Running target unix FAIL: gnat.dg/specs/coverage1.ads (test for excess errors) In order to reproduce, configure the compiler with Ada enabled, build it, and copy $[srcdir)/gcc/testsuite/gnat.dg/specs/coverage1.ads into the build directory, then just issue: gcc/gnat1 -quiet coverage1.ads -ftest-coverage -Igcc/ada/rts raised STORAGE_ERROR : stack overflow or erroneous memory access
On Fri, 2022-11-04 at 10:12 +0100, Eric Botcazou wrote: > > gcc/ChangeLog: > > > > * file-prefix-map.cc (remap_filename): Allow remapping of > > relative paths > > Small regression in Ada though, probably a missing guard somewhere: > > === gnat tests === > > > Running target unix > FAIL: gnat.dg/specs/coverage1.ads (test for excess errors) > > In order to reproduce, configure the compiler with Ada enabled, build > it, and > copy $[srcdir)/gcc/testsuite/gnat.dg/specs/coverage1.ads into the > build > directory, then just issue: > > gcc/gnat1 -quiet coverage1.ads -ftest-coverage -Igcc/ada/rts > > raised STORAGE_ERROR : stack overflow or erroneous memory access It took me a while to work out how to get ada to build. When I did I found it was faulting due to a NULL filename being passed to lbasename: Program received signal SIGSEGV, Segmentation fault. lbasename (name=0x0) at gcc/libiberty/lbasename.c:82 82 return unix_lbasename (name); (gdb) bt #0 lbasename (name=0x0) at gcc/libiberty/lbasename.c:82 #1 0x0000000000f3d566 in remap_filename (maps=0x0, filename=filename@entry=0x0) at gcc/gcc/file-prefix-map.cc:76 #2 0x0000000000f3d6df in remap_profile_filename (filename=filename@entry=0x0) at gcc/gcc/file-prefix-map.cc:158 #3 0x0000000000e59f59 in coverage_begin_function (lineno_checksum=lineno_checksum@entry=595732889, cfg_checksum=cfg_checksum@entry=2754642872) at gcc/gcc/coverage.cc:650 #4 0x00000000012263c0 in branch_prob (thunk=thunk@entry=false) at gcc/gcc/profile.cc:1400 #5 0x00000000013b1205 in tree_profiling () at gcc/gcc/tree-profile.cc:782 #6 (anonymous namespace)::pass_ipa_tree_profile::execute (this=<optimised out>) at gcc/gcc/tree-profile.cc:888 #7 0x00000000011ef30b in execute_one_pass (pass=0x36ebea0) at gcc/gcc/passes.cc:2644 #8 0x00000000011f0697 in execute_ipa_pass_list (pass=0x36ebea0) at gcc/gcc/passes.cc:3093 #9 0x0000000000e4c28d in ipa_passes () at gcc/gcc/cgraphunit.cc:2170 #10 symbol_table::compile (this=0x7ffff718f000) at gcc/gcc/cgraphunit.cc:2291 #11 0x0000000000e4ec08 in symbol_table::compile (this=0x7ffff718f000) at gcc/gcc/cgraphunit.cc:2271 #12 symbol_table::finalize_compilation_unit (this=0x7ffff718f000) at gcc/gcc/cgraphunit.cc:2543 #13 0x00000000012cfea0 in compile_file () at gcc/gcc/toplev.cc:471 #14 0x00000000009a727c in do_compile (no_backend=false) at gcc/gcc/toplev.cc:2125 #15 toplev::main (this=this@entry=0x7fffffffe21e, argc=<optimised out>, argc@entry=4, argv=<optimised out>, argv@entry=0x7fffffffe348) at gcc/gcc/toplev.cc:2277 #16 0x00000000009a8a8b in main (argc=4, argv=0x7fffffffe348) at gcc/gcc/main.cc:39 I can send the obvious patch to make it work as before and ignore the NULL which fixes this. I'm not sure if it should really be passing NULL around in the first place or not which is why I'm sharing the backtrace. Cheers, Richard
> I can send the obvious patch to make it work as before and ignore the > NULL which fixes this. I'm not sure if it should really be passing NULL > around in the first place or not which is why I'm sharing the backtrace. Thanks for the investigation. That's because the DECL_SOURCE_LOCATION of the function is UNKNOWN_LOCATION since: 2021-08-11 Bernd Edlinger <bernd.edlinger@hotmail.de> PR debug/101598 * gcc-interface/trans.c (Subprogram_Body_to_gnu): Set the DECL_SOURCE_LOCATION of DECL_IGNORED_P gnu_subprog_decl to UNKNOWN_LOCATION. That's indeed quite irregular but we have to live with it now.
On 11/7/22 01:01, Eric Botcazou via Gcc-patches wrote: >> I can send the obvious patch to make it work as before and ignore the >> NULL which fixes this. I'm not sure if it should really be passing NULL >> around in the first place or not which is why I'm sharing the backtrace. > Thanks for the investigation. That's because the DECL_SOURCE_LOCATION of the > function is UNKNOWN_LOCATION since: > > 2021-08-11 Bernd Edlinger <bernd.edlinger@hotmail.de> > > PR debug/101598 > * gcc-interface/trans.c (Subprogram_Body_to_gnu): Set the > DECL_SOURCE_LOCATION of DECL_IGNORED_P gnu_subprog_decl to > UNKNOWN_LOCATION. > > That's indeed quite irregular but we have to live with it now. Eric, can you push the approved fix for this issue (look for a message from Richard P day or two back, approved by Richi)? I'm dealing with a medical issue and heading offline again momentarily. jeff >
> Eric, can you push the approved fix for this issue (look for a message > from Richard P day or two back, approved by Richi)? I'm dealing with a > medical issue and heading offline again momentarily. Sure, done.
On Tue, Nov 01, 2022 at 01:46:20PM -0600, Jeff Law via Gcc-patches wrote: > > On 8/17/22 06:15, Richard Purdie via Gcc-patches wrote: > > Relative paths currently aren't remapped by -ffile-prefix-map and friends. > > When cross compiling with separate 'source' and 'build' directories, the same > > relative paths between directories may not be available on target as compared > > to build time. > > > > In order to be able to remap these relative build paths to paths that would > > work on target, resolve paths within the file-prefix-map function using > > realpath(). > > Understood. > > > > > > This does cause a change of behaviour if users were previously relying upon > > symlinks or absolute paths not being resolved. > > I'm not too worried about this scenario. This breaks ccache testsuite and -fdebug-prefix-map behavior in directories which are symlinks, see PR108464/ I can't see how the new behavior would be correct in that case, user is asking to remap say /home/jakub/foobar2 to some other path, but exactly /home/jakub/foobar2 appears in the debug info, rather than the other path. Jakub
diff --git a/gcc/file-prefix-map.cc b/gcc/file-prefix-map.cc index 24733f831d6..50d5d724a8f 100644 --- a/gcc/file-prefix-map.cc +++ b/gcc/file-prefix-map.cc @@ -70,19 +70,28 @@ remap_filename (file_prefix_map *maps, const char *filename) file_prefix_map *map; char *s; const char *name; + char *realname; size_t name_len; + if (lbasename (filename) == filename) + return filename; + + 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; }