From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 8UrSD36wBGoGrjYAWB0awg (envelope-from ) for ; Wed, 13 May 2026 13:10:22 -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=X7Vk22Yf; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 2E4921E0C3; Wed, 13 May 2026 13:10:22 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_INVALID,DKIM_SIGNED,HTML_MESSAGE,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 D70601E067 for ; Wed, 13 May 2026 13:10:17 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 85F4B4BB8F51 for ; Wed, 13 May 2026 17:10:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 85F4B4BB8F51 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=X7Vk22Yf 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 751F24BB8F7A for ; Wed, 13 May 2026 17:08:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 751F24BB8F7A 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 751F24BB8F7A Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1778692123; cv=none; b=T0Xk/7xEmolzauYXkxAqtEujLY12VcW/KrT7/68UmC3CJL8HSsJuV0hRJsf0j0gbhTz4D0c8aA6iEHOWfypuBHsk3HwZuQR+snsQmJd8AA1JO2i+Nu5BY95byW1TUKxbNwyhlXW+D/U5cQyvYxb1TaEpiN5K7rh1seFZixj1rFY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1778692123; c=relaxed/simple; bh=mgM67yWxnq35khnzo0sLgOg0QxkCZTnWGfSE22wQIIg=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=QZK7PI62c29iDgonzO+5Be5FvsTVnxfzs6qufGHuzUqX4TP3IIOK/4irIc+eMarmPhMkw2WPV3jIT/SCgrwWQEh6QTSwOQjwSpEdJ4CHBrrlNTKm7UUSkHmxB/3NJh7M6/BPxsy1z1XFgvJWDsJzdNptgLY6INgjLTHBt3uF9ZU= ARC-Authentication-Results: i=1; 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=X7Vk22Yf DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 751F24BB8F7A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1778692123; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=pYwPCBmz7NydkBZ8bojwFueZFofzJaHi9npaBw2wCwY=; b=X7Vk22YfZ6GHURzaMBpg48DbV0llIzLoEbCrmxcnF3qw2+5UwKLSXxpl2nnZLXK4PTqpN+ 5qA+VcQ1CGiKOzvaT7/2G29xecZbF3XinzzRCP2XhvBz716rKH+G8t5oPYQac6ElSoHpHv WHfd+biPGceMdMIGV+4zlf8aRJM6BJU= Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-94-z_l0jWxoPBumjdEOs_zzZQ-1; Wed, 13 May 2026 13:08:41 -0400 X-MC-Unique: z_l0jWxoPBumjdEOs_zzZQ-1 X-Mimecast-MFC-AGG-ID: z_l0jWxoPBumjdEOs_zzZQ_1778692121 Received: by mail-qt1-f200.google.com with SMTP id d75a77b69052e-50d812c898cso168561211cf.1 for ; Wed, 13 May 2026 10:08:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778692121; x=1779296921; h=in-reply-to:from:content-language:references:to:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pYwPCBmz7NydkBZ8bojwFueZFofzJaHi9npaBw2wCwY=; b=bAoAqtFBpTqZnjm4V3skTIni4GX0Q5lhJlhWoFbQvS38ijj7ZH3Rr2R1meERi0dKhY KDB/FAvNYi8zDq9NRARKWX1ziPFPA7i7ELkEAA9U2uWTUCALnvudF/bMNZTpS2ubbJZw J1hLKZF0agSwmvSPbUyxCmSJObw7I7fR3NtIA0duoWF+JuWbum2ACslNLI9T77fmLyy5 Gsc9gMe3gv1wROHDROlFQ4fk+jwm4NCnvM/LJzwTkGI7T+qy9ZJ3wHa086q1ixhTqzVu KmtEUDd15a6PRaIbXq9dBXRr+Vx4GI7U4AaHepJ3ZzJrQ1THP0KBPD8kH+77mrQJd5fI zGfQ== X-Forwarded-Encrypted: i=1; AFNElJ+MOYjgk0tagz276Ch5x2lNnFiNjvwJLh9JYfDUQI3dkYNPC4Pp5jBpwlcoLqo22JEnCykyna7e3U5Yeg==@sourceware.org X-Gm-Message-State: AOJu0YzuuvEkIM3FJyq89sACLP7EVXK5UPbdBIzaMP/lREv4WUi86d5U AudfEkWOQgdtZScn+jXGDa6ic4J/5JPlm12rVyp1PA0E+AYV0OJ9NS7oukJc6AZ57AEhwrTm9FN EClZw1NJ5+gmCgQiFlYjZ144bfF8FrdWzb3nGYbOqfE61pju1RDjyVOO8mZMfTLw= X-Gm-Gg: Acq92OGNvN7Yn7G4xpU9KlVTdMULSe5Ow9vwlQ3S1YXLHPmdyTQLJ2aebeODyCqbpsr jxGwPgKZJQ0Zy3m8GB7+IE+mzYGpQA6I8Vgku5LShWdHCFgcxtbwU9t3pgMQMvGa+Ims0JIPNBe HbRa9QTIN4+1/Czv1E15EX56xa/07r83qAUdvaJQU4bGmiS4aYfyuGzlVV2LXAe/wzT1TZ43eJe eSJdhO5znmGCNDEXBoZhiWm+00ren4c9eLqfUlUdzKpNJ8a9Dr5gtaqNxlN07miG6rX8iUBZNsD XBfwwaFtjNUy17q0h6eBNwcfOjD/WTb2ZdP2QQg7VKOatc6CS6zVdIXLGSinrq9QMxWKWqFCqnu +RHiqOaI+DZqxNaai3Bwmgivoa6GdEAc= X-Received: by 2002:a05:620a:40d1:b0:8cb:9975:cba8 with SMTP id af79cd13be357-90fae05a11emr574035085a.62.1778692120926; Wed, 13 May 2026 10:08:40 -0700 (PDT) X-Received: by 2002:a05:620a:40d1:b0:8cb:9975:cba8 with SMTP id af79cd13be357-90fae05a11emr574028885a.62.1778692120282; Wed, 13 May 2026 10:08:40 -0700 (PDT) Received: from ?IPV6:2804:14d:8084:993e::75d? ([2804:14d:8084:993e::75d]) by smtp.gmail.com with ESMTPSA id af79cd13be357-910bcf37274sm8309185a.37.2026.05.13.10.08.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 May 2026 10:08:39 -0700 (PDT) Message-ID: <9eaec41a-e96d-4a18-8c31-9469e2260dc2@redhat.com> Date: Wed, 13 May 2026 14:08:36 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 3/3] gdb: extend the [[N]]::foo syntax for files To: Andrew Burgess , gdb-patches@sourceware.org References: <20251029125831.2102647-1-guinevere@redhat.com> <20251029125831.2102647-4-guinevere@redhat.com> <87v7dl3brm.fsf@redhat.com> From: Guinevere Larsen In-Reply-To: <87v7dl3brm.fsf@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: FD0S835mBbevqqbJghrHa_Oy14Ie3exhzTjseJdb7dM_1778692121 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="------------4o1lsVA3drMUqDCdnwSUeSCE" Content-Language: en-US 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 This is a multi-part message in MIME format. --------------4o1lsVA3drMUqDCdnwSUeSCE Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/20/26 12:13 PM, Andrew Burgess wrote: > Guinevere Larsen writes: > >> This commit implements the missing support for [[N]]::'file.c'::var >> syntax that was skipped on the previous commit. >> >> This is done by adding a new value to the global parser_state, so that >> the classify_name function can restrict its search for file names to the >> specified linker namespace. It had to be done this way because if the >> logic was contained on the newly added "block: block COLONCOLON >> FILENAME" rule, we would not have the name to rerun the search. > Did you consider adding the filename to the type such that it > was available within the rule to allow for the filename to be re-looked > up? > > I'd be interested to know if this was tried, why this was worse than > pushing parser state back to the lexer, which I always thought was not a > great design. My one worry with this is, what if there is a file foo in the default namespace, and a function 'foo' in namespace 1 Could we misidentify this as being a filename, and then we rerun the search inside the "block: block COLONCOLON FILENAME" and find nothing, and raise an error when the expression was valid? I'm not familiar enough with our parser to know if this is the case, but if it is and I understand it correctly, I think this is a possible failure case... Although if you think this is a failure that is too niche, I can go that route, mark it as such on the code and commit message, and remove the linker namespace ID from the parser. -- Cheers, Guinevere Larsen It/she --------------4o1lsVA3drMUqDCdnwSUeSCE Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 4/20/26 12:13 PM, Andrew Burgess wrote:
Guinevere Larsen <guinevere@redhat.com> writes:


This commit implements the missing support for [[N]]::'file.c'::var
syntax that was skipped on the previous commit.

This is done by adding a new value to the global parser_state, so that
the classify_name function can restrict its search for file names to the
specified linker namespace.  It had to be done this way because if the
logic was contained on the newly added "block: block COLONCOLON
FILENAME" rule, we would not have the name to rerun the search.

Did you consider adding the filename to the <whatever> type such that it
was available within the rule to allow for the filename to be re-looked
up?

I'd be interested to know if this was tried, why this was worse than
pushing parser state back to the lexer, which I always thought was not a
great design.

My one worry with this is, what if there is a file foo in the default namespace, and a function 'foo' in namespace 1

Could we misidentify this as being a filename, and then we rerun the search inside the "block: block COLONCOLON FILENAME" and find nothing, and raise an error when the expression was valid?

I'm not familiar enough with our parser to know if this is the case, but if it is and I understand it correctly, I think this is a possible failure case... Although if you think this is a failure that is too niche, I can go that route, mark it as such on the code and commit message, and remove the linker namespace ID from the parser.

-- 
Cheers,
Guinevere Larsen
It/she
--------------4o1lsVA3drMUqDCdnwSUeSCE--