From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id CH35GD7Q8mmJ3wQAWB0awg (envelope-from ) for ; Wed, 29 Apr 2026 23:45:02 -0400 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=RSSOYvbh; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 36AA61E093; Wed, 29 Apr 2026 23:45:02 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.1 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_MSPIKE_H2,RCVD_IN_SBL_CSS, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=no 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 B38D31E093 for ; Wed, 29 Apr 2026 23:45:00 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 0B4814315075 for ; Thu, 30 Apr 2026 03:44:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0B4814315075 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=RSSOYvbh 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 BD5CB4A9C001 for ; Thu, 30 Apr 2026 03:44:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BD5CB4A9C001 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 BD5CB4A9C001 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=1777520671; cv=none; b=c5KxVulyawHkVIm8yieYPSybILrGrk/mWO99TnpA/REm1dGrpk+yaVCspBfs7HJdITe2Osxvsy0pju0OFhGTQy8m31NWpDFGg0g4AftZIKdAlmo39SQsZCrumIsqyf8AysmNcFOt+abEvJj8I1WIFOJAp6DUDNuja3cIF5Je7VE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777520671; c=relaxed/simple; bh=0qpi4kL3q3zSwykmQlJkpxv0VNSgxhd0mj/gwDm5Qu8=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=sNiplY0UEGyLk7RwZG6Y1vINGVMixnmhcdMlvw4qTYqlh3OMeYAyS06q1/81lUy7GhbbiLPWL4kaTmg0OLAkI9FkQxGw6XyUA9zGrcoQjX64U6/bnwnSncVeJJZ+DmabgWxYgQ22aD9NvlEIVfP5gGnkXYRJa2GmsXWLwl3rPdM= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BD5CB4A9C001 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1777520671; 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: in-reply-to:in-reply-to:references:references; bh=5S4sOPVCMy4nRcY06jp045ff1q74nRmrYUcfbHDyXZM=; b=RSSOYvbhqBKu5laovsQlFY7NOUOPS48/KityKEAjAwR6dKCNIdWki5HqO0XyRYp0UwWvc6 TErVly4xOSpxGr3HsKd5kablo/+y6oNXQmu3XPUztK3klppLgZuK6zwMh2ARIsJGIAwSAt XIj6i7yqHZAddmlWT004I6lQNS8dtyw= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-592-Jd0Kz68kM-qhVrHSbCES_w-1; Wed, 29 Apr 2026 23:44:27 -0400 X-MC-Unique: Jd0Kz68kM-qhVrHSbCES_w-1 X-Mimecast-MFC-AGG-ID: Jd0Kz68kM-qhVrHSbCES_w_1777520667 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (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-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 4CE811955F3C; Thu, 30 Apr 2026 03:44:26 +0000 (UTC) Received: from f42-zbm-amd (unknown [10.22.88.68]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id DC882180045E; Thu, 30 Apr 2026 03:44:24 +0000 (UTC) Date: Wed, 29 Apr 2026 20:44:22 -0700 From: Kevin Buettner To: Abdul Basit Ijaz Cc: gdb-patches@sourceware.org, tom@tromey.com Subject: Re: [PATCH 1/1] gdb, fortran: Fix local variable lookup in Fortran parser. Message-ID: <20260429204422.58ea6275@f42-zbm-amd> In-Reply-To: <20260429210720.150319-1-abdul.b.ijaz@intel.com> References: <20260429210720.150319-1-abdul.b.ijaz@intel.com> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: WIt7haY28njBapwB6yF_4dYFowzddPs9vLOOidf3vqE_1777520667 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Hi Abdul, On Wed, 29 Apr 2026 23:07:20 +0200 Abdul Basit Ijaz wrote: > This changes fixes https://sourceware.org/bugzilla/show_bug.cgi?id=34059. > > The Fortran expression parser in GDB ("gdb/f-exp.y") previously performed > symbol lookup in this order when parsing identifiers: > > - SEARCH_STRUCT_DOMAIN (types/structs) > - SEARCH_VFT (virtual function tables) I think that your parenthetical description of SEARCH_VFT is wrong. In symtab.h, it's defined as: /* A convenience define for "C-like" name lookups, matching variables, types, and functions. */ #define SEARCH_VFT \ (SEARCH_VAR_DOMAIN | SEARCH_FUNCTION_DOMAIN | SEARCH_TYPE_DOMAIN) > - SEARCH_MODULE_DOMAIN (modules) > > It searched for "types before variables", causing type names from shared > libraries to shadow local variable names. > > For a reproducer like the one given below, the Fortran parser fails to > look up local variable name "array" and treats it as a type value instead > of a variable, because there's a conflicting "array" type from system > libraries. > > 1 program test > 2 > 3 ! Declare variables used in this test. > 4 integer, dimension (-2:2) :: array > 5 > 6 array = 1 > 7 > 8 print *, "" ! Break here > 9 print *, array > 10 > 11 end program test > > Before the change, GDB shows: > > ''' > ./gdb --data-directory=./data-directory --args /tmp/a.out > GNU gdb (GDB) 18.0.50.20260408-git > Copyright (C) 2026 Free Software Foundation, Inc. > ... > Reading symbols from /tmp/a.out... > (gdb) break 8 > Breakpoint 1 at 0x11b3: file test.f90, line 8. > (gdb) run > Starting program: /tmp/a.out > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > > Breakpoint 1, test () at test.f90:8 > 8 print *, "" ! Break here > (gdb) info locals > array = (1, 1, 1, 1, 1) > (gdb) print array > ______ Attempt to use a type name as an expression > (gdb) ptype array > type = Type array > Type, C_Union :: :: u > PTR TO -> ( char :: scratch(0:15 )) > End Type array > ''' > > This issue is fixed in the Fortran expression parser in GDB > ("gdb/f-exp.y") by prioritizing SEARCH_VFT over other search domains > during symbol lookup. After the change, the 'array' variable is resolved > to the correct value. > > ''' > (gdb) print array > $1 = (1, 1, 1, 1, 1) > (gdb) ptype array > type = integer(kind=4) (-2:2) > ''' > --- > gdb/f-exp.y | 2 +- > gdb/testsuite/gdb.fortran/vars-lookup.exp | 38 +++++++++++++++++++++++ > gdb/testsuite/gdb.fortran/vars-lookup.f90 | 29 +++++++++++++++++ > 3 files changed, 68 insertions(+), 1 deletion(-) > create mode 100644 gdb/testsuite/gdb.fortran/vars-lookup.exp > create mode 100644 gdb/testsuite/gdb.fortran/vars-lookup.f90 > > diff --git a/gdb/f-exp.y b/gdb/f-exp.y > index 278e2091403..4216112c10b 100644 > --- a/gdb/f-exp.y > +++ b/gdb/f-exp.y > @@ -1651,8 +1651,8 @@ yylex (void) > struct block_symbol result; > const domain_search_flags lookup_domains[] = > { > - SEARCH_STRUCT_DOMAIN, > SEARCH_VFT, > + SEARCH_STRUCT_DOMAIN, > SEARCH_MODULE_DOMAIN > }; > int hextype; This fix makes sense to me. > diff --git a/gdb/testsuite/gdb.fortran/vars-lookup.exp > b/gdb/testsuite/gdb.fortran/vars-lookup.exp new file mode 100644 > index 00000000000..2c9be02f1dc > --- /dev/null > +++ b/gdb/testsuite/gdb.fortran/vars-lookup.exp I'd like to see a more descriptive name that describes this exact test. If the test were sufficiently general, testing all manner of fortran variables, then I'd be okay with the name you're giving it. Maybe something like "local-var-shadows-type" or "var-type-precedence"? Those are just suggestions. If you can think of a better name, then use that. > @@ -0,0 +1,38 @@ > +# Copyright 2026 Free Software Foundation, Inc. > + > +# This program is free software; you can redistribute it and/or modify > +# it under the terms of the GNU General Public License as published by > +# the Free Software Foundation; either version 3 of the License, or > +# (at your option) any later version. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program. If not, see . > + > +# Test the variable lookup. Perhaps say a bit more than "Test the variable lookup", above? > + > +require allow_fortran_tests > + > +standard_testfile .f90 > +load_lib fortran.exp > + > +if {[prepare_for_testing "failed to prepare" $testfile \ > + ${srcfile} {debug f90}]} { > + return > +} > + > +if {![fortran_runto_main]} { > + return > +} > + > +set bp_loc [gdb_get_line_number "break-here"] > +gdb_breakpoint "$srcfile:$bp_loc" > +gdb_continue_to_breakpoint "stop-at-bp" ".*$srcfile:$bp_loc.*" > + > +set integer4 [fortran_int4] > +gdb_test "print array" "= \\(1, 1, 1, 1, 1\\)" > +gdb_test "ptype array" "type = $integer4 \\(-2:2\\)" An unpatched GDB will only fail if debuginfo from a system library is present and loaded with a conflicting 'array' declaration, right? I'd like this test to somehow replicate that scenario without requiring the system library. Perhaps create a shared lib that is loaded with this test that has a suitably conflicting declaration / definition ? Kevin