Re: [PATCH] Add wildcard matching to substitute-path rules

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 4 Apr 2024 02:05:11 +0200
> CC: <gdb-patches@sourceware.org>
> From: Max Yvon Zimmermann <max.yvon.zimmermann@campus.tu-berlin.de>
> 
> 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.