From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 7ty6IHm+g2kXxygAWB0awg (envelope-from ) for ; Wed, 04 Feb 2026 16:47:37 -0500 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Qbj1kiPi; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 781901E08D; Wed, 04 Feb 2026 16:47:37 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED,RDNS_NONE autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (unknown [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 87D1C1E08D for ; Wed, 04 Feb 2026 16:47:36 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 093B44BA2E0C for ; Wed, 4 Feb 2026 21:47:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 093B44BA2E0C Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Qbj1kiPi Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id C785D4BA543C for ; Wed, 4 Feb 2026 21:47:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C785D4BA543C Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C785D4BA543C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1770241628; cv=none; b=MZ2BfXknww56ZMVvVpOiCNz4D370oALdX7TnZeHaBVIPaoC6hMRNilZnD5yW1yyuTcmd5r6cSQtuHj3hGmP5zj+e6NIK9IQw1bvNfP0BPh0ebH1yeyoX6qLHuzPP2B6+Z3Vn23gap3IoTYb/NGwy5NC4HJyOgFMVT1xNxDIZvT4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1770241628; c=relaxed/simple; bh=PmHmN5qD3D9p6g5C3BnXRUGaUEuvH00411zCgOdP+/4=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=I5zOS9gzDLWCu+HzqIIS3Rl+MIKdkQUyKaCH0UxbBnOHVu/h1cNpjIrjI0pCEBJRdVH6JN8XdxOBPHEJ3a29/TTArJ1kieIRfYZzgJUPJ6HVoKPswpvpFZoFUoupzjlFNYSaSStkU1XdTZOMrDyHKCPFl2fPCdSnkDZ267kqfCI= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C785D4BA543C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770241628; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ot5azimeM1ZEzqfHqiG/0zDFd1vBNPWbRM0gXYQ1ZoI=; b=Qbj1kiPif9Z2ouq/ErygTSJEIvpFbM/plW9mb+b7Xc2iA0wKQ89WotJy2TtFLjSpK7kkWu /W9rL0+iakIRK00In/uOyUmWtx3oj9FMdZgt/LaRYgydTgr7e4yAnTFvdn8PEjMEVv+dNb OJIqJel4dotlO4h9QJdjIu+dR0/D92M= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-650--O7XgFzxMIeAJbo-LinW-A-1; Wed, 04 Feb 2026 16:47:06 -0500 X-MC-Unique: -O7XgFzxMIeAJbo-LinW-A-1 X-Mimecast-MFC-AGG-ID: -O7XgFzxMIeAJbo-LinW-A_1770241625 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-48071615686so2193565e9.1 for ; Wed, 04 Feb 2026 13:47:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770241625; x=1770846425; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ot5azimeM1ZEzqfHqiG/0zDFd1vBNPWbRM0gXYQ1ZoI=; b=QIt3XcSpJ3oWGAXmdT8P4RriCyGDJwAmpTjUD13tj7jYmRqB8ihc8hxZS/wy0N9+P5 xAC7XQmh1umCq8w+RWJXaMs8VWpsefywCyde/q5AJMcsnP2frFvwvWA6GRHbjcKRCjCt 9NhcxLL8MR/bK1Uo8dc/IKzoEXQy9Kqx6lrA4FJn3FOnax0XeKdWsK3nyO5oz49NpTrd quW9S1gedMpSA+m4wrwES7blNCz5Z5WylQYxD3iM3mT6Ot0m1euYVP47Ua3S0xZ18wXT 9CoVKWTcyeBTMpCfMcWPMfzTOZCQfZ+YlLhbZ+mbDyurwL77MpRlxkfTrJuuME/Jn3DI u1tQ== X-Forwarded-Encrypted: i=1; AJvYcCXKQVxyMbNbgnu6/NuO7ENnrf1vZWCztCKGsBt/H2pgq3Cttco12L3eBeyzGVp4FLVcUTMlFyPbRRu8SA==@sourceware.org X-Gm-Message-State: AOJu0Yytxm6g8V5uFOdNL9+obybzqDyNGgFsacS6xbgDngvhhyTE/Gpz c6llOeD59lp76WwX7TNCZW65+jN0oHA0AQTmPr7eF3y6CfK8w/MrxJJuk5lVm+D1AJPCIBEECbI Al+uxMPYvo2dDDhAXvs7i1OdUwoMWY+ByzpWbvIrBlD5BSBdJADRbZKUzvlskKdI= X-Gm-Gg: AZuq6aJTiTELDliIC5vWz+xzG4EILJ5YYXCPffiCNlLv+fsmm2L6JeJvcmKM6ez2kFR 5N+Oa/+oW4KQB7RfFKz5e7wMOk+y6NWNTPHLzge/Iai6eB+JwtyPlcr4qWPDttHgfhfVByGz1OV Lqo5K1w3chFIZFSUgMpuBbarNqdKVUy28abZ7khOmnneLbAVKU8vol5im5OVjN/7pt5H/qorbmE Mv37IKUdaGO3egLJHT+GueLfIVm1Fx0sX/+YqLGq7XTk5EoaUqiRWGobnC77/2JF043OF1hfE5O aQN03Pi4sqN0twxh04RkKy+p2edWdK9th7auKzzUp6CWR0uJVffdf/mUefFLZ4e3u1iCtNbe4xZ dDW7W X-Received: by 2002:a05:600c:871a:b0:47e:e61d:b8d2 with SMTP id 5b1f17b1804b1-4830e976f0fmr63011705e9.27.1770241625314; Wed, 04 Feb 2026 13:47:05 -0800 (PST) X-Received: by 2002:a05:600c:871a:b0:47e:e61d:b8d2 with SMTP id 5b1f17b1804b1-4830e976f0fmr63011425e9.27.1770241624813; Wed, 04 Feb 2026 13:47:04 -0800 (PST) Received: from localhost ([31.111.84.232]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43618058473sm9399317f8f.22.2026.02.04.13.47.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Feb 2026 13:47:04 -0800 (PST) From: Andrew Burgess To: Guinevere Larsen , gdb-patches@sourceware.org Cc: Guinevere Larsen Subject: Re: [PATCH v2] gdb: fix filename matching in skiplist_entry::do_skip_gfile_p In-Reply-To: <20260203185528.946918-1-guinevere@redhat.com> References: <20260203185528.946918-1-guinevere@redhat.com> Date: Wed, 04 Feb 2026 21:47:03 +0000 Message-ID: <87ldh8dvvs.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: IET7ak4o92IwQtMHhSSszH97scyPsFkb0c4JE5xUoNI_1770241625 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Guinevere Larsen writes: > GDB is incorrectly matching -gfile skip entries. This is a regression > introduced by the following commit: > > commit 02646a4c561ec88491114b87950cbb827c7d614c > Author: Fangrui Song > Date: Sun Dec 29 14:57:44 2024 -0800 > > skip -gfile: call fnmatch without FNM_FILE_NAME > > The author made the reasonable, but unfortunately incorrect, assumption > that glibc's fnmatch, and consequently gdb_filename_fnmatch, will return > the integer equivalent of a boolean (that is, 0 if the filenames do *not* > match, non-zero if they match), but that is incorrect. This made it so > using `skip -gfile` would skip all functions except the ones that are > meant to be skipped. This commit fixes that inverted logic. > > This incorrect matching masked a different bug, that we were treating > all user-provided gfiles as absolute paths, and the gdb.base/skip.exp > test happened to not catch it because the "skip.c" file is different > enough to exit earlier in the comparisons. This was solved by making it > so if the gfile is not absolute, the regex "*/" is prepended, allowing > for any number of directories before the first user-provided one, but > ensuring that the beginning of the directory must match what the user > provided. > > The limitation of this approach is that, if a user has given the regex > "a/c*.c", and the inferior contains both "/b/a/code.c" and > "/c/a/code.c" and is running on the folder /b, functions from both may > be skipped when it would be reasonable for the user to expect only > /b/a/code.c to be skipped. This is done anyway because I believe the > likelihood of something like this actually happening is incredibly low, > and it was the behavior of GDB before the aforementioned commit so we'll > just be returning to previous behavior. For what it's worth, I'm not convinced by the original patch. Sadly there are no tests with the original patch, but based on the commit message I think what they original wanted was, given a directory tree like: /usr/include/first_header.h /usr/include/dir1/some_header.h /usr/include/dir2/other_header.h They can just: (gdb) skip -gfile /usr/include/*.h And skip all three headers. The problem I have with this is that I can no longer skip just the files in one directory, so given: /foo/file_a.c /foo/bar/file_b.c I can no longer do: (gdb) skip -gfile /foo/*.c And only skip 'file_a.c', the '*' here will always match both 'file_a.c' and 'bar/file_b.c', which I think is unfortunate. I wonder if a better approach would be to add something like bash's '**' globstar feature, which matches 0 or more sub-directories. In the original case the user could then: (gdb) skip -gfile /usr/include/**/*.h This would match all three headers from the original example. And in the second example: (gdb) skip -gfile /foo/*.c Would still only match 'file_a.c' as it currently does. If we wanted to match both, then: (gdb) skip -gfile /foo/**/*.c Would do the trick. Unfortunately, fnmatch doesn't support '**' matching, so we'd have to roll our own, but I think it would be worth it. Given the above, my vote would be to not merge this fix, but instead revert commit 02646a4c561ec8849111, then we could make an attempt at adding a '**' feature. We could merge this fix, but doing that would make the changed behaviour that commit 02646a4c561ec8849111 tried to introduced actually work, at which point people might start depending on it. Right now 02646a4c561ec8849111 is broken, so revering it, even though it made it into GDB 17, should be OK I think. Anyway, that's just my thoughts, not sure how others will feel. Thanks, Andrew > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33872 > --- > gdb/skip.c | 15 ++++++++++++++- > gdb/testsuite/gdb.base/skip.exp | 15 +++++++++++++++ > 2 files changed, 29 insertions(+), 1 deletion(-) > > diff --git a/gdb/skip.c b/gdb/skip.c > index 1255c7d2152..5770d6251a8 100644 > --- a/gdb/skip.c > +++ b/gdb/skip.c > @@ -548,7 +548,20 @@ skiplist_entry::do_skip_gfile_p (const symtab_and_line &function_sal) const > /* Note: symtab_to_fullname caches its result, thus we don't have to. */ > const char *fullname = symtab_to_fullname (function_sal.symtab); > > - result = gdb_filename_fnmatch (m_file.c_str (), fullname, FNM_NOESCAPE); > + /* If the pattern does not correspond to an absolute path, add a glob > + that accepts any leading path. While this is not technically > + correct, it is very likely that a user wished to skip /a/b/code.c and > + not skip /c/b/code.c, and both files are relevant to the project. > + Plus, this is how GDB has always worked, so users are likely expecting > + that behavior. */ > + std::string glob = "*/"; > + if (IS_ABSOLUTE_PATH (m_file.c_str ())) > + glob = m_file; > + else > + glob += m_file; > + > + result = gdb_filename_fnmatch > + (glob.c_str (), fullname, FNM_NOESCAPE) == 0; > } > > if (debug_skip) > diff --git a/gdb/testsuite/gdb.base/skip.exp b/gdb/testsuite/gdb.base/skip.exp > index 4541e61ec00..7cec1fc7021 100644 > --- a/gdb/testsuite/gdb.base/skip.exp > +++ b/gdb/testsuite/gdb.base/skip.exp > @@ -336,3 +336,18 @@ with_test_prefix "skip delete completion" { > test_gdb_complete_none "skip delete a1" > test_gdb_complete_none "skip delete 2-33" > } > + > +# PR gdb/33872 was a regression that would happen when using > +# skip -gfile and a full path had to be matched. The logic had > +# been inverted and it wold skip all files but the one with the > +# one we wanted to skip > +with_test_prefix "PR gdb/33872" { > + gdb_test "skip -gfi /unused/path/*" \ > + "File\\(s\\) /unused/path/\\* will be skipped when stepping\." > + > + if {![runto_main]} { > + return > + } > + > + gdb_test "step" "bar \\\(\\\) at .*" > +} > > base-commit: a6d46a04ea3e165c0ce2f11cd9d68bdcb81f4e4e > -- > 2.52.0