From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id TNWtHYm+52mNnzAAWB0awg (envelope-from ) for ; Tue, 21 Apr 2026 14:14:33 -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=J4BZ17Df; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 659C61E093; Tue, 21 Apr 2026 14:14:33 -0400 (EDT) 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_MSPIKE_H2,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 612AF1E093 for ; Tue, 21 Apr 2026 14:14:32 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 627B34BA23E7 for ; Tue, 21 Apr 2026 18:14:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 627B34BA23E7 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=J4BZ17Df 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 F1C1B4BA23C3 for ; Tue, 21 Apr 2026 18:14:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F1C1B4BA23C3 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 F1C1B4BA23C3 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=1776795244; cv=none; b=WnqpxyYcKQ96fL5g9wGPJSM0sT/5jr4x97aAurR1LMY/uC4kKRUONHixU3yIGTqoWbxW/li0+1jEdlj7JHz6Uh0YUj6kXO6T6NSjyCz9CNaxIutAaiaIbG2+rMWvvl7ucEOaMynEwKjuz+vU99wZ6WqEZ+efjnOLRVneJ7EjwqI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776795244; c=relaxed/simple; bh=IsnWsAxOX6JD2V6pnZlmXo29FT4+KvOgRKgtUkn2T1U=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=khg5Y3JCRQAKIrDQneYcAb6OGdEKPzBHJwL+Zk+LDbApCS+1zmTecLUxXrRtMeViOqlTSALWG8vnWci2t1RdntUJn9biwfWj695AoBIFoKgWLs44PtIxSLB9QeWVV/sGjdbn0d7JIwrQ8w/+mnrFnYdqs/mWaSDxoDfeNovENx4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F1C1B4BA23C3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1776795243; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=l5Jao4k0AAaYAN4VzNH4soJOCL3jChcJJL2L6hQRPZY=; b=J4BZ17DfxikQTWtsAcHm1UHgLISgR0qJYfZuV3nsnO1AVbwo48jW6YMuS/zxQ8cA+j/m2E 48ttDbqtpu/P1mXKLz04HSAIUZU1R3u6+37GW9uI0ef1PGTIUXjMJY14dly82LpQtI7G81 2fIOSx4s/TB2bqk//bhmsT3Hl7ShOkI= Received: from mail-pl1-f198.google.com (mail-pl1-f198.google.com [209.85.214.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-412-XgW6DziYOVWrR0CFmuetbg-1; Tue, 21 Apr 2026 14:14:01 -0400 X-MC-Unique: XgW6DziYOVWrR0CFmuetbg-1 X-Mimecast-MFC-AGG-ID: XgW6DziYOVWrR0CFmuetbg_1776795241 Received: by mail-pl1-f198.google.com with SMTP id d9443c01a7336-2b250d3699aso94050585ad.2 for ; Tue, 21 Apr 2026 11:14:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776795240; x=1777400040; h=content-transfer-encoding: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=l5Jao4k0AAaYAN4VzNH4soJOCL3jChcJJL2L6hQRPZY=; b=W3QcPLszDoNM+Pr9bhP9023x8D7AWInEc59RPZ4otsgcXUpuJ8eKXBA9FURE8xNLYa 0kHA8eT/pSTGS4ayU44Ga0vtsTegdZGWa5As+/iTayRTFU7+1mO4BARvpXKr4gGhkZ3Y RcIS0HCsvF4qUmmQqpBeYYwAYNa3DPqVZLfrrgMnzw+a0YrrT8Ai/dZXFD/ly4Q2/CjP wfewb+7UFnMUb9JDRV9fyNJPbXojPvalcLboBUjVYGGU5+VTjIDln0sx+jNpLe9mU7oP kp3xiw1lzBl8Ls2NARLusU0FL7qTE+3bcQPb/D9MA+vq/25ktgpmIrqj1i5Ve23DvSC0 L+1Q== X-Forwarded-Encrypted: i=1; AFNElJ++NH/dLfS+LR6td4YVNCG/bWrMWI+5jnMC80d7062G+49ATNo23W5uQu7Cm5WXlzDpaXxoONp5qYMZ3A==@sourceware.org X-Gm-Message-State: AOJu0Yz84IYGFVOBMQlJFN6CyHuIYftXXdGFYqNYIlUuvNmaHZRbRTYW lauuRz/JE8wLiPKlY4LkrQsISuI4e5ylw4MYyiovs0xRuH3KR4aUHl5WXwdnMX6ZT2XsSwpUtnU KjhUYK9iQ7MeuxfOSl9NFDg2mZ6PxV6UJkggTbX/+ye60Ty3/dudYSjHqos7dgc3bQYQzPIg= X-Gm-Gg: AeBDieuXReEQWf02q8/9tL9of5qFb/EHNh+5++nXCBUQimqE67kin/x/xVfIpWkKDZm ka9HlptATzZWCOfSr2f6wiTjMjdgf5HUfW6MMU26nG/LI2luEzU+Z4NSAt5F274jshe1eoWDdOd HA03U0DgtDpqxCPR2YTZugLscpsUAXULkdfNI8WYFquzLRZV+d++HSWgPWaWOYLqLgDoEpIW1F5 +jH+btCdMRdA+zUxfgeAvfWXR27KyWdx5SQiQP/G7zj7+E8GuExV7oS5FEuAzzVarnMaTdJybAm rnCBMDa4xf7AX+8ZAe4Sc2IN0F7y2AG8lZ+3nD4iRL50yBr2EiGNTgHuTlgz9mGkblRpylE3WFp MYjOAVSanZ1UYQ+K/JZFVhENH4tg21Xgh45vBwCs= X-Received: by 2002:a17:903:11d0:b0:2b2:ec00:7966 with SMTP id d9443c01a7336-2b5f9f1ab06mr212004685ad.21.1776795240214; Tue, 21 Apr 2026 11:14:00 -0700 (PDT) X-Received: by 2002:a17:903:11d0:b0:2b2:ec00:7966 with SMTP id d9443c01a7336-2b5f9f1ab06mr212004265ad.21.1776795239473; Tue, 21 Apr 2026 11:13:59 -0700 (PDT) Received: from [150.1.200.157] ([172.56.107.181]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b606ce9891sm104985805ad.83.2026.04.21.11.13.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Apr 2026 11:13:59 -0700 (PDT) Message-ID: Date: Tue, 21 Apr 2026 11:13:57 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Add infcall support for C++ constructor-style expressions To: Andrew Burgess , gdb-patches@sourceware.org References: <87cxzs2zxj.fsf@redhat.com> From: Keith Seitz In-Reply-To: <87cxzs2zxj.fsf@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 4OEMDicl8uTrjSJnoO9uCBG3t5cw8jjywacLE4ic6ZQ_1776795241 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed 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, On 4/21/26 6:41 AM, Andrew Burgess wrote: > Keith Seitz writes: > >> diff --git a/gdb/c-exp.y b/gdb/c-exp.y>> index a4a910df712..e17ee2d3c12 100644 >> --- a/gdb/c-exp.y >> +++ b/gdb/c-exp.y >> @@ -3114,6 +3140,34 @@ static int popping; >> built up. */ >> static auto_obstack name_obstack; >> >> +/* Return TYPENAME_CTOR only when the next token is '(', so this >> + token is used solely for constructor calls. Otherwise return TYPENAME. >> + NAME_END is the character just past the name (e.g. yylval.sval.ptr + >> + yylval.sval.length). */ >> + >> +static int >> +typename_token_for (struct parser_state *par_state, struct type *type, >> + const char *name_end) >> +{ >> + if (type == nullptr >> + || par_state->language ()->la_language != language_cplus) >> + return TYPENAME; >> + type = check_typedef (type); >> + if (type->code () != TYPE_CODE_STRUCT && type->code () != TYPE_CODE_UNION) >> + return TYPENAME; >> + /* Only return TYPENAME_CTOR when followed by '('. */ >> + if (name_end == nullptr) >> + return TYPENAME; >> + { >> + const char *p = name_end; >> + while (*p == ' ' || *p == '\t' || *p == '\n' || *p == '\r') > > Would 'c_isspace (*p)' work here? It's what we use in similar cases > within this file. Absolutely! >> diff --git a/gdb/eval.c b/gdb/eval.c >> index 7beff554ed4..e988b954059 100644 >> --- a/gdb/eval.c >> +++ b/gdb/eval.c >> @@ -1869,6 +1869,61 @@ type_operation::evaluate (struct type *expect_type, struct expression *exp, >> error (_("Attempt to use a type name as an expression")); >> } >> >> +value * >> +type_operation::evaluate_funcall (struct type *expect_type, >> + struct expression *exp, >> + enum noside noside, >> + const std::vector &args) >> +{ >> + struct type *type = std::get<0> (m_storage); >> + type = check_typedef (type); >> + >> + /* Constructor-style call Type(args) is only for C++ aggregate types. */ >> + gdb_assert (exp->language_defn->la_language == language_cplus); >> + >> + const char *name = type->name (); >> + if (name == nullptr) >> + error (_("Cannot call constructor of unnamed type")); > > Thinking about this error was interesting. [snip] > Then I extended the type_exp rule like: > > type_exp: > ... snip ... > | TYPENAME_CTOR > { > pstate->push_new ($1.type); > } > > All of the new tests still pass... > > ... but the decltype example still doesn't work. But by this time I was > curious, clearly my actual example with global_var is never going to > work, the global_var type doesn't have a constructor, but what if > global_var was a type that did have a constructor? The decltype trick > should be workable, right? > > So, I guess the question I'm circling around here is, instead of adding > typename_for_ctor, did you try just using the existing type_exp rule? > Even if we didn't get the decltype trick working in the original commit, > it feels like going through type_exp would leave that as a possibility > for the future, but going with typename_for_ctor feels like it will make > that harder. I did at one time use a similar approach. I think what happened is that I ran into issues and started breaking down/isolating my changes to make sure that it wasn't some other production messing me up. Alas, I did not actually go back and try to integrate my working solution. I will investigate further for v2. > >> + >> + /* Get the constructor name from the type name. */ >> + gdb::unique_xmalloc_ptr ctor_name_ptr = cp_func_name (name); >> + const char *ctor_name = (ctor_name_ptr != nullptr) ? ctor_name_ptr.get () : name; > > This line seems a little long, maybe wrap at the '=' ? > >> + >> + if (!overload_resolution) >> + return operation::evaluate_funcall (expect_type, exp, noside, args); > > I've pretty sure that this path, calling operation::evaluate_funcall, > will always result in an error like: > > (gdb) set overload-resolution off > (gdb) p U(34) > Attempt to use a type name as an expression > (gdb) > > I wonder if it would be clearer to the user to just do: > > if (!overload_resolution) > error (_("Constructor calls require 'set overload-resolution on'")); That is a much more user friendly approach that I will adopt in v2. > I didn't see any tests with 'set overload-resolution off' in use, so it > wasn't clear if there's maybe some path where the function call as you > have it can do anything other than throw an error? I'll add this test, too. >> + std::vector argvec (1 + args.size ()); >> + value *this_ptr; >> + if (noside == EVAL_AVOID_SIDE_EFFECTS) >> + this_ptr = value::zero (lookup_pointer_type (type), lval_memory); >> + else >> + { >> + value *alloc_val = value_allocate_space_in_inferior (type->length ()); >> + this_ptr = value_from_pointer (lookup_pointer_type (type), >> + value_as_long (alloc_val)); >> + } >> + argvec[0] = this_ptr; >> + for (size_t i = 0; i < args.size (); ++i) >> + argvec[i + 1] = args[i]->evaluate_with_coercion (exp, noside); >> + gdb::array_view arg_view = argvec; >> + >> + value *callee = nullptr; >> + int static_memfuncp; >> + find_overload_match (arg_view, ctor_name, METHOD, >> + &argvec[0], nullptr, &callee, nullptr, >> + &static_memfuncp, 0, noside); > > It would not be usual for constructors to be static, but we should > probably handle the case where static_memfuncp is true, even if it is > just: > > if (static_memfuncp) > error (_("Constructor %s is unexpectedly marked static"), name); > > Bonus points for using the DWARF assembler to exercise this error case, > but I don't think that's a hard requirement, I see this error more as a > glorified todo marker -- if we ever find a case where this is triggers > then we can understand it, and fix GDB to match. I will add this. > >> + if (callee == nullptr) >> + error (_("Cannot resolve constructor %s to any overloaded instance"), >> + name); > > I don't think this error case is being tested. Can you add a test case > for this? Boy, I've spent a lot of my day today trying to trigger this error. I am convinced it cannot be done. I'm passing METHOD to find_overload_match, which will always call error() when no matching symbol is found. Thus I think it best to replace this error check with an assertion. > >> + >> + if (noside == EVAL_AVOID_SIDE_EFFECTS) >> + return value::zero (type, not_lval); >> + >> + evaluate_subexp_do_call (exp, noside, callee, arg_view, >> + nullptr, expect_type); >> + return value_ind (this_ptr); >> +} >> + >> } >> >> /* A helper function for BINOP_ASSIGN_MODIFY. */ >> diff --git a/gdb/testsuite/gdb.cp/infcall-ctors.cc b/gdb/testsuite/gdb.cp/infcall-ctors.cc >> new file mode 100644 >> index 00000000000..053542ec5ea >> --- /dev/null >> +++ b/gdb/testsuite/gdb.cp/infcall-ctors.cc >> @@ -0,0 +1,128 @@ >> +/* This testcase is part of GDB, the GNU debugger. >> + >> + Copyright (C) 2026 Free Software Foundation, Inc. >> + >> + This file is part of GDB. >> + >> + 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 . */ >> + >> +struct S { > > The '{' should be on a new line. This mistake is repeated throughout > this test, I'll not point them all out. > >> + int x; >> + explicit S (int n = 0) : x (n) {} >> + S operator+ (int n) const { return S (x + n); } >> +}; >> + >> +typedef S S_td; >> +using S_u = S; >> + >> +static int add (const struct S &s1, const struct S &s2) { > > Newline before add, opening '{' on its own line. Unless this layout is > needed for the test? In which case a comment is needed. Nope -- just like a lot of the other silly formatting issues, I simply over-relied on my new editor to "do the right thing." I'll fix all the errors you've mentioned. Thank you for your review! [I'll submit a v2.] Keith