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

[Max Yvon Zimmermann <max.yvon.zimmermann@campus.tu-berlin.de>]

Sorry, I need to make a correction. This topic can be a bit more confusing at times than I initially thought.

>>> 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.
> 
> This is a very fair point. Having different files map to the same file in the local source directory could be annoying.
> Because this isn't a new issue per se, I thought about implementing a separate patch that would warn the user if two different files get mapped onto the same source file.
> But after some thought I realized that there are actually valid use-cases for this multi-mapping.
> 
> Let's say we have the following directory structure:
> 
> /inc.h
> /foo.c
> /dir/bar.c
> 
> '/foo.c' includes '/inc.h' via #include "inc.h".
> '/dir/bar.c' includes '/inc.h' via #include "../inc.h"
> 
> With GCC this will result in two entries in the debug info: '/inc.h' and '/dir/../inc.h'.
> For GDB these entries are two separate files. (Maybe this could changed with another patch though)
> But with the help of the following two rules we can tell GDB to treat them the same:
> 
> set substitute-path /from /to
> set substitute-path /from/dir/../ /to
> 
> I therefore don't know if multi-mapping should be considered wrong here.
> Also I don't think that glob matching would make this more common due to the aforementioned direction of the mapping.
> For me, this is a completely separate issue.

The rule

set substitute-path /from/dir/../ /to

would actually never match because '/dir/../inc.h' (inside '/from') would also match '/from' which is defined first.

Also you could make the case that this is not really a multi-mapping, because '/inc.h' and '/dir/../inc.h' are, of course, the same file.
But it makes implementing a usable warning more tedious.
Maybe a warning to the user is actually the right solution here but I'm not entirely sure.
What are your thoughts on this?