From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id BYz0NFKTjGksvzUAWB0awg (envelope-from ) for ; Wed, 11 Feb 2026 09:33:54 -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=Q9muAvgn; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id BFAE21E08D; Wed, 11 Feb 2026 09:33:54 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.4 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 autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [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 D07C01E08D for ; Wed, 11 Feb 2026 09:33:53 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 518E54BA23CB for ; Wed, 11 Feb 2026 14:33:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 518E54BA23CB 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=Q9muAvgn Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id 1C9D54BA2E0A for ; Wed, 11 Feb 2026 14:33:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1C9D54BA2E0A 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 1C9D54BA2E0A Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1770820407; cv=none; b=LE5QNPXHibgKUmmza6KkJMF8Dy0UPcfvoCWUcKw1rGoul7H12Q6ajE1hPxWAxXRpFBaFyGilNs4lSVCX4YBhifrEqihPb0b+CThhFO+WjokuykOKcAOxCFPL/EhTZeBe+YPP+kPQq5C/zaPiTzAuizjQJXkXS3POMO91wGArgFg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1770820407; c=relaxed/simple; bh=3zE5nxwR6uSp29ZSMtgfyEDBQlF/3JgKe2qEzJpKF3E=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=Ncdqoj7NSLUgBnQjzyW2QniBqgNNon/Qy4w5qQKhQkViG46CMR8eZ7ny9xG6oyzKIVX4MlMsWsmYIdbp/bUJTKHY2p6MzjDBWVs6AzVmK65diF8jBAd9X1fCrVVAIL6IdzTlbM/YI4pEabqdwjFOcgOto4FZH+CzfSYi2thevZ0= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1C9D54BA2E0A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770820406; 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=ZXg/Q3oLsZE/Jqvx410pKznR4Yl6yygiWyEgTY0hAa4=; b=Q9muAvgn/XUL2wynU+jkagzNcYLroSK2W6Jbr1JldNA21+XFGavEy8Glr80/+Uz1yNtHcO beWm9bYVZqNR5Pop0rv1hQ86gWIVF8mJ1eM3yTS+6MuY9x2txXz3JpGhH4QWtL7ljb0Wsa yhhklHKiRAor1B7bX1xSKPEsvSuOGf0= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-53-oUF-zmRmPxKiAopOfF8IIA-1; Wed, 11 Feb 2026 09:33:25 -0500 X-MC-Unique: oUF-zmRmPxKiAopOfF8IIA-1 X-Mimecast-MFC-AGG-ID: oUF-zmRmPxKiAopOfF8IIA_1770820404 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-47ee3dd7fc8so48842945e9.3 for ; Wed, 11 Feb 2026 06:33:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770820404; x=1771425204; 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=ZXg/Q3oLsZE/Jqvx410pKznR4Yl6yygiWyEgTY0hAa4=; b=LTmsY2qXUTRbuYDY1DUNMph5nIuv3/VIVBjHzZD6uZ4ujop2mLKn0Xa8bk3Zh2BoEd gVvrIRK00Y9/Y8buz2bZj60XHfmYEelmmiHKaukq21+yHbpTO1MW5ypWX8yvElwb4Stu kYn+ZL3xxd9X0ePfnY76CcOrp4lDkD/nNmnUzhSpUFDI+h7riwGaFJeax/su32pgQ/zN h2t5NLA3QEqgmxkoFfZl5mgO89cTyp9s4hH+ENUbVxmoeBsAYcEKTmnNFrr0kRupE53e 3wRja0wL3oX8Uo+weE+ErTrplfTVt03NNkG/XEgtmKfBjLPfxPajDEfuovWYQ8t/+M4s cSQA== X-Gm-Message-State: AOJu0YwTuGJsLJ56yRSpD0IP9GobaiDbuW6h5hFLeXnrZHOi24xSgF94 xsi5nzFAijsN/fgezPMd3i2b2K98F72GzbC+Ed9OuzPmK2u+MQvgeU2fTZ9rSTp0WOnYKTyUrjf fMJHqWMCH19C+9jcqO3OvWzrD+qc9LCXF5d9B2xoZ1IiHPAciQu3c/GbKkWiHiOpaK7i5x30UlN QRWpKJJHNqLOZ3o7sJeAxsQa26jsfqT309Z7yF2kQHU9Ce8ag= X-Gm-Gg: AZuq6aLzxamTDYXp2DVmymOBdOLOQwNepjHKltAR/HZi/pp64tNgF9Y+9cPMldx3PsX ntVXQhfBEoAKTUuZ1sT/dt2qxte1YSPsVMDVdWC4u+2C+eZ0rGTPMJ/isqmNIe33ZmTpwAolEAy TL3bOjkR+rJYcqZkKGfYt+cpX3AZbk486Ekad101QBODyVknqfBk81iYDV0L5RCUPj/uXKOLAPv r4E81sUrB9qss/d+Nm+BIWgs7AkBjR993Q8fNtiAndvwZFfPoShHKnbPAXJhkiozdJ6Xbahx4Az I+tqqVd+1E45WT5cOHXvFSoRYLtDRu8z1jTXUeD4XWLMv9HrOu9nkOsee7iVhiMDLnQeArZNidr j5Z6Ydv+MSI+aDRcv X-Received: by 2002:a05:600c:1552:b0:477:a978:3a7b with SMTP id 5b1f17b1804b1-4835b95316cmr34734075e9.22.1770820403786; Wed, 11 Feb 2026 06:33:23 -0800 (PST) X-Received: by 2002:a05:600c:1552:b0:477:a978:3a7b with SMTP id 5b1f17b1804b1-4835b95316cmr34733735e9.22.1770820403244; Wed, 11 Feb 2026 06:33:23 -0800 (PST) Received: from localhost ([31.111.84.232]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4834d7e50casm123431655e9.8.2026.02.11.06.33.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Feb 2026 06:33:22 -0800 (PST) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Guinevere Larsen , Fangrui Song Subject: Re: [PATCH v2] gdb: fix filename matching in skiplist_entry::do_skip_gfile_p In-Reply-To: <871piuc5jc.fsf@redhat.com> References: <20260203185528.946918-1-guinevere@redhat.com> <87ldh8dvvs.fsf@redhat.com> <871piuc5jc.fsf@redhat.com> Date: Wed, 11 Feb 2026 14:33:21 +0000 Message-ID: <87o6lvbb9q.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: dLPmwF4oS1VAdwvWw5T_krsa8JNveYEkAgx7dGC4924_1770820404 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 Andrew Burgess writes: > Andrew Burgess writes: > >> 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. > > CC-ing Fangrui Song (original patch author). > > I'm planning to revert commit: > > commit 02646a4c561ec88491114b87950cbb827c7d614c > Date: Sun Dec 29 14:57:44 2024 -0800 > > skip -gfile: call fnmatch without FNM_FILE_NAME > > In the gdb-17-branch and master branch on Wednesday. As the bug the > Guinevere mentions, this patch has introduced a regression, and as I > believe I have shown, this patch has changed GDB behaviour in a > non-backward compatible way. > > I'll then take a look at implementing support for '**' as mentioned > above as I believe this will solve the original issue in a backward > compatible way. > > If any other global maintainer disagrees with this plan, speak out and > I'll not go ahead with this. I've now reverted this patch in gdb-17-branch and master. I've posted this series: https://inbox.sourceware.org/gdb-patches/cover.1770819471.git.aburgess@redhat.com which implements the '**' idea. Feedback welcome on that thread. Thanks, Andrew