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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 4 Apr 2024 10:52:31 +0200
> CC: <gdb-patches@sourceware.org>
> From: Max Yvon Zimmermann <max.yvon.zimmermann@campus.tu-berlin.de>
> 
> Actually, this is already mentioned in the documentation. But maybe it can be made a bit clearer. On the other hand, I really do not want to encourage the extra \-escaping. I am thinking of writing something like this instead:
> 
> "On DOS-based file system, you are encouraged to use '/' as the path separator within your patterns. This avoids escaping the '\' characters and would still match against file names that use '\' as the path separator. For instance, the pattern 'C:/foo/*' would still match 'C:\foo\bar'."

I'm not sure this should be in the manual, since the way file names
are written in the debug info is not under user's control.  If the
file names in the debug info use backslashes, will GDB recognize
rewrite rules that use forward slashes?  Even if GDB does treat both
characters as equal on Windows, I'm not sure users will trust that up
front, so they might use backslashes in the rewrite rules anyway.

> > 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?
> 
> No, rules that use wildcards are still processed in a predictable way. If we set the following two rules (and in that order!):
> 
> set substitute-path /foo/include /path/to/foo
> set substitute-path /*/include /path/to/somewhere
> 
> Then any file names matching '/foo/include' would be rewritten to '/path/to/foo' and NOT '/path/to/somewhere'. Even though any file name matching '/foo/include' would of course also match '/*/include'. The rule selection is entirely based on the order of their definition.

That's not what I meant.  I meant that a rule like

  set substitute-path /*/include /path/to/somewhere

can catch any parent directory of 'include', and which one it will
catch is not known in advance.

> Also, in the example I stated in my last reply, no file name that matches '/foo/include' would ever match '/bar/include'. The point I was trying to get across was that two unrelated files can already be mapped onto the same file (accidentally).

Well, two wrongs don't make a right.

I'd be interested to hear opinions of others about this.