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

[Guinevere Larsen <blarsen@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2447 bytes --]

On 4/4/24 08:52, Eli Zaretskii wrote:
>>> 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.

This was something I was also wondering about. taking from the original 
example:

Max> In the case of conan (https://conan.io/) the path will consist of 
some constant part and some directory named with some hash value (i.e., 
/path/to/<unique hash>/builddir/)

Suppose there are 2 builds for this package, so we have the following 
valid directories: /path/to/deadbeef/builddir /path/to/00000000/builddir

which of those will be chosen? Is it consistent across gdb runs? OSs? 
How can a user know in advance which will be picked?

>
>> 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).

The difference I see is that in the previous examples, the problem is 
apparent within what the user would expect (some GDB script, debug 
information, or other things related to their project), whereas with 
glob matching, the problem may be unrelated (directory structure of 
unrelated folders).

If I wasn't aware of this patch, I would never think to check if the 
folder structure of my system could be the problem for getting debug 
information.

> Well, two wrongs don't make a right.
>
> I'd be interested to hear opinions of others about this.


-- 
Cheers,
Guinevere Larsen
She/Her/Hers