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 E26593858C98 for ; Thu, 4 Apr 2024 11:52:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E26593858C98 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 E26593858C98 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=1712231561; cv=none; b=uwTuWngCGFEeL1mjE/O+1AZauAlEqf8PpN7+cGMVpQbUpZ5JPvkN+PRk3JqEsAcflgYMV58t+b5DEcKybPMKEORajgQwhb66jhsd/hrsROi1+nYYeGsSY93UHb9wm/GP9+M6XXExLfWeBUJxfjYbL6ZnxJ7qWT0d9j1sBwdy38k= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712231561; c=relaxed/simple; bh=W/R7sEsrCO7rxznNJ+kOx/FG5HpKPY0fax1AhqsnnXk=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=Slj0uVA7rcSavWzRalqfQguPS3tdlc2eKdyZ4IEkCZDDsW2gIvpB1LGHnUfCw91htCxXQcCiBWVV1crBtJ6O9gRe4kcgmZ/T/r5RpmZz9NkqQMyD+PdJMvtqaT1MiRMfQfjliCjbLl2Dlk2x/yzheWhQ8QKMnc7VV5RuAylVoy4= 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 1rsLe1-0008AP-G0; Thu, 04 Apr 2024 07:52:37 -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=XhwR6hKlyV+iHGUsIk17m9UtV3+29imHOS/nqOKzh+A=; b=jmNdm7peuEAP VAdGJSolwxBTAxbDtkWmxfeZALiyltf/HMFxO0UmFcugsOEQjDzPDKQgbBxrCSkY0W9TzFpYOExCz ufRRGovmH+YUsskVx81X1iJ5cjeIY5nfl0gI97B/rnGNEwmUgArhbFwl/HPT15b12DwQYllITjWUN zkDoETIo81etiDrNCTSR594UDT9kXpXQF2RQJZFLKszaU8RRpD6x+Cb50vIvWKNPNNK4dUSWMRL0l s0hmOU5AT0biDI3BOM66f4z1vHvFn/E8Gvk6Bb750PQ9tovh8YnXTGG0xg+gyuHnveYh0YG1qLlWm K3QZFU+MJiQ7EO0hMOebfA==; Date: Thu, 04 Apr 2024 14:52:34 +0300 Message-Id: <86zfu973b1.fsf@gnu.org> From: Eli Zaretskii To: Max Yvon Zimmermann Cc: gdb-patches@sourceware.org In-Reply-To: (message from Max Yvon Zimmermann on Thu, 4 Apr 2024 10:52:31 +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> <867chd8yh6.fsf@gnu.org> 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 10:52:31 +0200 > CC: > From: Max Yvon Zimmermann > > 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.