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 E35D53858C78 for ; Tue, 2 Apr 2024 12:25:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E35D53858C78 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 E35D53858C78 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=1712060741; cv=none; b=B/L0FHkHNI1F2mCvdEQnCBO1aafMi6KpARFLixCVkIha7E+A79uM2rlkmgNgvRbwHbMYR91u7CPBn4oe/uuCUCDctw0vZCYH0P0DqUQwRbFlQv0dcSMPh892xR8ahEYg1sXV3cj0COMb/9fyBLl+pz1XXPiX2WfrtYw8SC+dVIY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712060741; c=relaxed/simple; bh=zzWlcXe2QyNuJeUeuXgTLLbc+QtCJzVEUYUlPhH701E=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=YOd6v/61vN45vzFZyxj5MUUrkQbNiXNx3eAWuGpnNVf7K17JLFDlyQgNAYK9Z35OAp/573WOoWBcpemlZVIMVeMKg/PS/IjFypjVMbeltGs/eJKJHnab8yytme0vxmWqDcxTDTcR8GSu8EBjidR8Xwd5qc1QsssFAC6uVJQb06w= 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 1rrcbD-00005D-K5; Tue, 02 Apr 2024 07:46:45 -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=gnId/LDCiIhDNS07vgyzNTS7sef6XYKvA43oCcfrPXM=; b=B29qKre5Nam/ X2LCF06XKKmjZ8+kiAE3pkx+lwZJUYQl9UatlNcbrybWDfR3RMJiBxNRU9jzzh8Eyjqyw6MIQsIWR gJh4IuEYhYO7xwq/EcgCwqRp0rZv0K2ByndiZheUHfATqztMinDw/NwPxGy2vl53bJVdnEnEdZO71 y2YLXStn1wPcGRGeFnzYUkoQSNiYWhwHVrN/NVpGUobSG4v2e8/Ne/oZ0OKVbRc3aqW41ZR2VG1Eq Z9BIcuC4+0aXC4KYj0VcYNjuZCOSIY2s6giv7wwSgXuemTy5z4th4di9pegHVD5odvN/AloYPADO7 wC5uZb7rQDHbxNusCUiPvA==; Date: Tue, 02 Apr 2024 14:46:40 +0300 Message-Id: <86o7as9ecf.fsf@gnu.org> From: Eli Zaretskii To: Max Yvon Zimmermann Cc: gdb-patches@sourceware.org In-Reply-To: <5ff720ec-4453-441e-ba82-84d60a2e8d50@campus.tu-berlin.de> (message from Max Yvon Zimmermann on Mon, 1 Apr 2024 23:26:36 +0200) Subject: Re: [PATCH] Add wildcard matching to substitute-path rules References: <5ff720ec-4453-441e-ba82-84d60a2e8d50@campus.tu-berlin.de> X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,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: Mon, 1 Apr 2024 23:26:36 +0200 > From: Max Yvon Zimmermann > > I have developed a patch that allows for glob pattern matching within substitute-path rules. Thanks. > diff --git a/gdb/NEWS b/gdb/NEWS > index feb3a37393a..5a041175507 100644 > --- a/gdb/NEWS > +++ b/gdb/NEWS > @@ -90,6 +90,11 @@ show unwind-on-signal > These new commands replaces the existing set/show unwindonsignal. The > old command is maintained as an alias. > > +set substitute-path > + This command now supports glob pattern matching for substitution > + rules. Wildcards '?' and '*' are supported. Use '\' to escape > + '?', '*' and '\' characters. This part is approved, documentation-wise. 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?? > --- a/gdb/doc/gdb.texinfo > +++ b/gdb/doc/gdb.texinfo > @@ -9954,6 +9954,35 @@ For instance, if we had entered the following commands: > use the second rule to rewrite @file{/usr/src/lib/foo.c} into > @file{/mnt/src/lib/foo.c}. > > +Rules can contain wildcards to match multiple paths. The supported > +wildcards are @samp{?} (to match any single character) and @samp{*} > +(to match any string). Wildcards will never match the path separator of > +the system. File names of their parts should have the @file markup, not @samp. (Wildcards are file names of sorts.) > +For instance, if we had entered the following command: > + > +@smallexample > +(@value{GDBP}) set substitute-path /usr/*/include /mnt/include > +@end smallexample 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? > +Use @samp{@backslashchar{}} to escape the characters @samp{?}@comma{} > +@samp{*} and @samp{@backslashchar{}}. Note that you need to escape any > +@samp{@backslashchar{}} characters twice in the @value{GDBN} command line. I'd prefer not to use @comma{} and @backslashchar{} except where the literal characters will confuse TeX. AFAIU, they are not needed here, and literal characters will do the job. > + if (IS_DIR_SEPARATOR (path[last])) > + { > + path[last] = '\0'; > + > + if (path[last] != '\\') > + return; Something's wrong here: you assign path[last] and then test its value? Also, how does this handle Windows-style file names with backslashes? > +#ifdef HAVE_DOS_BASED_FILE_SYSTEM > + /* On DOS-based file systems, the '/' and the '\' are equivalent. */ > + if (pattern_c == '/') > + pattern_c = '\\'; > + if (string_c == '/') > + string_c = '\\'; > +#endif Does this mean "//" (two slashes in a row) will be converted to "\\", and will then be interpreted as an escaped single backslash? Reviewed-By: Eli Zaretskii