From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id uV/lFu9EgmnQVyYAWB0awg (envelope-from ) for ; Tue, 03 Feb 2026 13:56:47 -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=CweeeA5c; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 59AAB1E08D; Tue, 03 Feb 2026 13:56:47 -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 CC27F1E08D for ; Tue, 03 Feb 2026 13:56:46 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 683E94BA2E13 for ; Tue, 3 Feb 2026 18:56:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 683E94BA2E13 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=CweeeA5c 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 C9CFB4BA543C for ; Tue, 3 Feb 2026 18:55:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C9CFB4BA543C 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 C9CFB4BA543C 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=1770144944; cv=none; b=O4m8jfpBdoD/nEO8TQ6KlZST2BKjii4BZxMQkAlpmHuQakxVX78sxhh4K6vJ1zYbk4hZm20pJchWieL5jBvAMjhcoZPpL7sgekwPCgIaOAUxcI5rhXGjZLCTXqChZI8wyNlHWGzC5wCNxNxHNaSw4ApRZJvsCAslSARVzpTA43w= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1770144944; c=relaxed/simple; bh=cgA689a7n+ZO09V56rXXvGAQz/Gq1SKvd0J98xarkl8=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=wZbDTLkgxPPBXoaly84/sTMsd+kT3GngIDG1y/6fkDrXP/oS0bA8wTGnjBVvLnFRYl5eNVRrMtnd2bydO9z5dTTud4t5+Itk7iPlxiNkMRqfQXKAZksvHhnjQtnFAaZbVx5XfJvaOB4BQ8KrYawgTEOXcoRVtsxhUYWCPifOjnk= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C9CFB4BA543C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770144939; 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: content-transfer-encoding:content-transfer-encoding; bh=y578jKNCgRNxQjM/fXPWb7DRA1a4qJE3CUPZqZ2+rJI=; b=CweeeA5cpwwh2VBWSEyaa7JDKW3Y+VjA6ocriux9AQ1PKEDY/fP1/XvOgZ3840OBQ7ifMG 4oXY4eCszHuLV6kxXpcy7kZXoyopFZMyar6uGpgr5IBA/BvPA2NiorEaw2bAceZIJii27V jljatMJk0VxSA3b4jntzrfv9z3LHJHc= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-496-UN81d6zMNjSVTMqGg8nEAw-1; Tue, 03 Feb 2026 13:55:38 -0500 X-MC-Unique: UN81d6zMNjSVTMqGg8nEAw-1 X-Mimecast-MFC-AGG-ID: UN81d6zMNjSVTMqGg8nEAw_1770144937 Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 7646918005B4 for ; Tue, 3 Feb 2026 18:55:37 +0000 (UTC) Received: from fedora.tailb97d54.ts.net (unknown [10.96.134.67]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 08E4F1955F22; Tue, 3 Feb 2026 18:55:35 +0000 (UTC) From: Guinevere Larsen To: gdb-patches@sourceware.org Cc: Guinevere Larsen Subject: [PATCH v2] gdb: fix filename matching in skiplist_entry::do_skip_gfile_p Date: Tue, 3 Feb 2026 15:55:28 -0300 Message-ID: <20260203185528.946918-1-guinevere@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: MTv6i8SU2GBc0lBGOjSaYCcf9Y15xWQstB9ZX17DJm4_1770144937 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit content-type: text/plain; charset="US-ASCII"; x-default=true 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 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. 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