From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailrelay.tu-berlin.de (mailrelay.tu-berlin.de [130.149.7.70]) by sourceware.org (Postfix) with ESMTPS id DD0973847725 for ; Thu, 4 Apr 2024 00:05:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DD0973847725 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=campus.tu-berlin.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=campus.tu-berlin.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org DD0973847725 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=130.149.7.70 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712189141; cv=none; b=QwF9cwn5cwji6uAjsKVRV00nyg+opltV09d+5bWVrUpY7dRFEZDAGkaK8nZeawzrvowHexG1WQdVNLDuKKHiWu1KuSQ2+F14NHyDVao6CRm24kKjvrstIK5SJc8RO1hM2Hymdwy1AYVwkUGwHW64HmN4AYw9dxe6durh8i/dfRw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712189141; c=relaxed/simple; bh=2SA0shswmkCuYzy5nnnjrqi5n/24wGEypx4Lq+Q6sWM=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=cORKFBzUSnb49DpjrWJAKHsqVmkhOTEFZ+dG7ps7OnN15PomjHc5ihVq7D0ypTWZ+omtwpfwz5dpPzDz6mna7DdcGgJaAZhVWX9IXB+cKhUe2MylhQCdg0HvCRTXk55ies7PQRHqcc2hjxYuAOwdSuFLlz9n3LrGjSS2w8HLWIQ= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tu-berlin.de; l=4864; s=dkim-tub; t=1712189139; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=nO3JZssFs2DqbgYs47SP5g6DBFpB7HK95H98972+dVM=; b=FCVHdvjv/SJMBK1ocZmuza/mFDDwFrQTKliOLeGSV/BqY4ulMvpMXODR 7S8omBb04blWeJBCvp45CpB+mDPj1YukEgpn3vXgb4FcaVyrB6IMYebhf Al5SpwZar532ndZlKWoVeyMAOrjlQ/N/NDFn2/xOZ2GhUytrt7OzdDrrn I=; X-CSE-ConnectionGUID: FcEr9wz8Qce0nuU29l87OA== X-CSE-MsgGUID: 6Jaifmi9Q2e34kHvdTMbWg== X-IronPort-AV: E=Sophos;i="6.07,178,1708383600"; d="scan'208";a="7265166" Received: from mail.tu-berlin.de ([141.23.12.141]) by mailrelay.tu-berlin.de with ESMTP; 04 Apr 2024 02:05:37 +0200 Message-ID: <7eb59d60-1092-4b68-b019-d145d8fe8ab1@campus.tu-berlin.de> Date: Thu, 4 Apr 2024 02:05:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Add wildcard matching to substitute-path rules To: Eli Zaretskii CC: References: <5ff720ec-4453-441e-ba82-84d60a2e8d50@campus.tu-berlin.de> <86o7as9ecf.fsf@gnu.org> Content-Language: en-US From: Max Yvon Zimmermann In-Reply-To: <86o7as9ecf.fsf@gnu.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-13.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,GIT_PATCH_0,SPF_HELO_NONE,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: Thank you for the quick reply! >> 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?? On DOS-based systems both backslashes and forward slashes are valid path separators. So while Windows users COULD write their paths as \\path\\to\\, /path/to/ would work as well. This behavior is not new, the previous version behaved similarly. New is that to match a backslash from the GDB command line you would have to escape a backslash twice (because the CLI already unescapes backslashes). But because everyone can just continue to use forwards slashes, I think this should be fine. >> --- 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.) Ok, I will change that. >> +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? I realize now that /usr/*/include is actually a terrible example for this feature. I will change the example to avoid confusion. However it is correct that two files from distinct directories COULD accidentally get matched. But you could argue that this is already the case. Let's say we set the following two rules: set substitute-path /foo/include /mnt/include set substitute-path /bar/include /mnt/include Then we could run into exactly the same issue. I would also like to point out that the rule selection is unaffected by this patch. To quote from the documentation: "In the case when more than one substitution rule have been defined, the rules are evaluated one by one in the order where they have been defined. The first one matching, if any, is selected to perform the substitution." I think this should prevent any accidental matches if the feature is used correctly. >> +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? Yes, this is a bug. I actually wrote this function specifically for DOS-style file names. The idea is that any trailing backslash (that should be deleted) will be preceded by another (escape) backslash that must also be deleted. I will post a V2 soon where this function is getting a major overhaul and the relevant edge cases are included in the testsuite. >> +#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? No, this is only done for the comparison directly below. The pattern is not altered in any way. "//" will not result in an escaped single backslash.