From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 55EAB3858D34 for ; Thu, 4 Apr 2024 05:54:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 55EAB3858D34 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 55EAB3858D34 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712210055; cv=none; b=o6m+KXnpnHBWWZl+kbAWSrft6F5kiCF0wD9S1TpYwG+qp/Wu8wHp3W8DX6OM73sRiaoPJ1vvatvAJexYNisv0nTGypGs9DVKQ9DJ+b3l6AWCGjfaSbxxTN7WL8CT3cfWtBUSa3J0MIHCl+Brf6uPEeh0RdNnyl60x2cnVGRJzCY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712210055; c=relaxed/simple; bh=kyC50kouScG68ijleISDyI3rvcEead5/VFcSbktY6V0=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=ni19A824Kq1JwJOWk9S8dRvxyRi9UCDnreLT84a8v4hwmzpID76ql/3gW9e+eRXDQ8eVqKj7lKBUxRyaSu2MNKkFW+Jil1x/RcpjJvu8vqHpic283wIKRP7j2LBppIAq5CbOYgB3v2P8DRIPUa9wHWPJtTCGlZ6szOvrV9GWII4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rsG38-0001rb-KB; Thu, 04 Apr 2024 01:54:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Z1RAWNr/kcm1G+nQNuaZxyDu/csj+fhY00GnRMLr2zk=; b=mb0VvBM9qXMz kNqVZK1OqzxovjsAHHVmqZCGosPFnnxAMXJz0B1XBQoTK/bCP3Ds1y+elrA89FgQXD6zdL4KyzFpe OUrD4/3J9zfNF8sjqOCOqVeyg08kWkyKUfLFHxWSD2OWNmJh2KUa7/BtypOb4UMxfFcwDeV+bYRXq d9O7JO5buhpifjTrfx4VhtCtevC8pJ2JNxSKakWcZbCOZ0F78Tq4pjdldDFqC+fGDIDnviDK1XrjE S3PN89IXHB9Smj7/jryrgSET9i10U1n1ZYfoza4mt51AK7o5Y/hsn/xdSmrZWYJBzZ9RqBfKcHkCJ 39TUDA80usBw3MW6bb+NJQ==; Date: Thu, 04 Apr 2024 08:53:57 +0300 Message-Id: <867chd8yh6.fsf@gnu.org> From: Eli Zaretskii To: Max Yvon Zimmermann Cc: gdb-patches@sourceware.org In-Reply-To: <7eb59d60-1092-4b68-b019-d145d8fe8ab1@campus.tu-berlin.de> (message from Max Yvon Zimmermann on Thu, 4 Apr 2024 02:05:11 +0200) Subject: Re: [PATCH] Add wildcard matching to substitute-path rules References: <5ff720ec-4453-441e-ba82-84d60a2e8d50@campus.tu-berlin.de> <86o7as9ecf.fsf@gnu.org> <7eb59d60-1092-4b68-b019-d145d8fe8ab1@campus.tu-berlin.de> X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > Date: Thu, 4 Apr 2024 02:05:11 +0200 > CC: > From: Max Yvon Zimmermann > > Thank you for the quick reply! Thank you for working on this feature in the first place. > > But I wonder what does the above mean for Windows file names that use > > backslashes as directory separators? Does each backslash need to be > > escaped by another one, when creating the rewrite rules?? > > On DOS-based systems both backslashes and forward slashes are valid path separators. So while Windows users COULD write their paths as \\path\\to\\, /path/to/ would work as well. This behavior is not new, the previous version behaved similarly. New is that to match a backslash from the GDB command line you would have to escape a backslash twice (because the CLI already unescapes backslashes). But because everyone can just continue to use forwards slashes, I think this should be fine. So extra \-escaping will still be needed for DOS-based filesystems. I think this should be mentioned in the documentation. > > Does this mean that multiple /usr/*/include directories could be > > redirected to the same /mnt/include directory? Won't that cause > > trouble, if there are several distinct directories recorded in the > > debug info whose names match the wildcard, and which are supposed to > > resolve to different directories? > > I realize now that /usr/*/include is actually a terrible example for this feature. I will change the example to avoid confusion. However it is correct that two files from distinct directories COULD accidentally get matched. But you could argue that this is already the case. Let's say we set the following two rules: > > set substitute-path /foo/include /mnt/include > set substitute-path /bar/include /mnt/include > > Then we could run into exactly the same issue. The difference here is that the two lines above must be explicitly written by the user, whereas the wildcard rule could catch another directory unintentionally. > I would also like to point out that the rule selection is unaffected by this patch. To quote from the documentation: "In the case when more than one substitution rule have been defined, the rules are evaluated one by one in the order where they have been defined. The first one matching, if any, is selected to perform the substitution." To me, this means that the two-line example you've shown is processed in a predictable way, by only using the first one if both match, whereas a wildcard rule will cause unpredictable results, because the order in which files are compared against a wildcard is undefined. Right? Thanks.