From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id etGrCjLdgGmbhiQAWB0awg (envelope-from ) for ; Mon, 02 Feb 2026 12:21: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=I3VBURV6; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 1C29B1E08D; Mon, 02 Feb 2026 12:21: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=-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_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 957D51E08D for ; Mon, 02 Feb 2026 12:21:53 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 179824BB58C3 for ; Mon, 2 Feb 2026 17:21:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 179824BB58C3 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=I3VBURV6 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 F251E4BA9035 for ; Mon, 2 Feb 2026 17:21:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F251E4BA9035 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 F251E4BA9035 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=1770052887; cv=none; b=ValUTzxPzwMLCopdwcGt8vgj4N+ex4CaH7VU7QnyQVDc6bd6e2eAXETF2YgEEp7fHTmE5yyEvIpX7XvHfkmEbU35h1YCITQbJLXUzVXH+AgxBxswk1yrqgRBy7ke7jdoG/cpaBsidv3focCq1yytwFEN4cz/qIKYO1akYqb1aXQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1770052887; c=relaxed/simple; bh=IjHjWH7e2CHmCQgZbpamYwFGMYBgNQPRuN5jI6znaT4=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=EjO8MDML9Ai+9PhR5Z03cx9TwIsQNsRgyat+PNdO4YFeldYt3FBQeCutnFsWvGbu/55GRWW40g9EP1Sx2LOlh9Us9K1se4Zj+ytaBn8/BPHT3owgCnia/568fmP28/vLSX4hR+vq435iL4Od+/LImKd9y4NWiCQdAOpt3OR1s9s= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F251E4BA9035 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770052886; 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=d+Cl/tPlvgA64w3yE2vY05qeTvSLBicrXCIOFGz8AxY=; b=I3VBURV6YHiXeFg43foFTyMIpPN/EVk3Dxz5duE7fJmZkdYZIhoImnerjIQ6YC+x3cLnHd LxR3UpgnsOAJKxsgBUp5LA2T3lSTjgItDNuGYyKk4ZQXlhEV67o5ir2d9lW1VNPQzsjOgl I/6JOAhCRvZL78SD9jBwD8EkgfvYmkM= Received: from mail-pf1-f198.google.com (mail-pf1-f198.google.com [209.85.210.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-616-fcymqgl3PH6ztO6-nfoQLQ-1; Mon, 02 Feb 2026 12:21:22 -0500 X-MC-Unique: fcymqgl3PH6ztO6-nfoQLQ-1 X-Mimecast-MFC-AGG-ID: fcymqgl3PH6ztO6-nfoQLQ_1770052881 Received: by mail-pf1-f198.google.com with SMTP id d2e1a72fcca58-81c68fef4d4so11268232b3a.2 for ; Mon, 02 Feb 2026 09:21:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770052879; x=1770657679; 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=d+Cl/tPlvgA64w3yE2vY05qeTvSLBicrXCIOFGz8AxY=; b=TJj9VWnObbfLOq3bEwppTgyAcOF9arI4WABClBhw7bIw6LGpTLge6lThZn4YJeA8j1 XY7bH5UZl903fH8a99orgiFsMbH+rVLHodo5yWL+7sleJAvGaQF41T7Tuqxhn33+Wta4 f+qEa5nZ2uZ1Ru5aGJ14PBfTqUjsPhB7ogJQjZ74TTCEe31cNXahQnlwVmXnL2Kkzlwg GSgvpFvx+fRmcZHy52UvFLNJitar0QB0h6lSrWa1iMUaxxjTuQhLgkS4J1IuKxl/MjCK yzPRjxM4nsujI74hRguHhBL75xZApOTSoIWJD23IvPLzM+BkhQ44X0jyzt5jmfnt5ZZE fCbA== X-Forwarded-Encrypted: i=1; AJvYcCW2eUqhzVy/ZAJSU+/aaMBCMLwGj+DbRhWcIsqsDowiABqgTTgkQMYEo1E2+96zYCcSNiVcFO4YDeSdzg==@sourceware.org X-Gm-Message-State: AOJu0Yy0oLgGwQJLJu2eHsPt3ZOdjVmzxwSm7tVyTpjjIM/JMc5Aq9DA tSxigNcGXdmKRvQqkkYj+SrczGajAfZdB2/WuNaOMQ7IvhhfJ16luIu+6soNCTarKVgJ8g38JJK hQZ/r07RMzNluLq9r2yBqyJY73KO1fYq204c1A9GZdlkP9t7sfWW8l0iwd30SeSI= X-Gm-Gg: AZuq6aLj4dfngUAOgLO/4hZHFHoEjD+8Hz6YCTmKVMzVdE21FUx8u7Ltb6SGPiV845z ywqCd2QJ8/dUzQnf0JDsZik97ARO95fOnGuH2V3iMTRiQaMbbA/dO5wqtK3nCPHbhh1KSBbVPZH Cg/ogHGdjL8njiieZjsYyKbFVIQ24Avw1ntzZYPWElo/oToczNKKEHXXUOVXSs+WgoCRdc8OofN RgS3znUC3Tk3947/e6Fx3saz+UDPkAkf3Ti89YDYaVvKiCXmgMUpzJWOroEuGuztc0GYWXoG1Dq TmcmbKqhWoXDJFFqQEY9lDSWiuu6YLUBnmmQYB+IjEAZT2TEhtw6kCu3mkGEMyvNPNqKOSSarFk xo9SNIuHhe0R3ZAKD X-Received: by 2002:a05:6a00:3982:b0:81f:3a83:9756 with SMTP id d2e1a72fcca58-823ab676d3dmr11824084b3a.30.1770052879420; Mon, 02 Feb 2026 09:21:19 -0800 (PST) X-Received: by 2002:a05:6a00:3982:b0:81f:3a83:9756 with SMTP id d2e1a72fcca58-823ab676d3dmr11824072b3a.30.1770052879068; Mon, 02 Feb 2026 09:21:19 -0800 (PST) Received: from [150.1.200.157] ([172.56.106.185]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-82379bfb924sm17000942b3a.34.2026.02.02.09.21.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Feb 2026 09:21:18 -0800 (PST) Message-ID: Date: Mon, 2 Feb 2026 09:21:17 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4] infcall: Add support for integer literals as reference function paramters To: Andrew Burgess , gdb-patches@sourceware.org References: <92575c2eb6805095b41ebbe62ba99b81e4e5dd63.1760629738.git.keiths@redhat.com> <963c933a79455dc4aaa35f8c34bed8693065e6a5.1769539110.git.keiths@redhat.com> <87h5s5g7vt.fsf@redhat.com> From: Keith Seitz In-Reply-To: <87h5s5g7vt.fsf@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 0HHAKHGFOxsD-otkSPHqQnv3MXuQ4x0ADiQxDxHmXPs_1770052881 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, Thank you for looking at my patch. On 1/28/26 5:54 AM, Andrew Burgess wrote: > Keith Seitz writes: > >> Changes in v4 >> - Allocate to stack instead of heap > > I'm interested by this change. Within value_arg_coerce, a few lines > before your change, there's this comment: > > /* Force the value to the target if we will need its address. At > this point, we could allocate arguments on the stack instead of > calling malloc if we knew that their addresses would not be > saved by the called function. */ > arg = value_coerce_to_target (arg); > > I don't believe there's anything stopping the inferior function taking > the address of the reference argument and storing it. Could you explain > this change a little more? Hmm... I see where you're headed with this, and I had not thought of this possibility. This would certainly provide a counter- argument to a previous review suggesting stack allocation. However, if we malloc memory to hold this integer during the function call, is this also not free'd after the call returns? That pretty much leaves us in the same dilemma. [Pardon my ignorance; I am just learning this code for the (nearly) first time.] >> - Use value::force_lval to simply copying to inferior memory >> - Add some addition tests >> >> Changes in v3 >> - Move logic to value_arg_coerce >> - Add some attempt to limit copying to trivially copyable types >> --- >> gdb/infcall.c | 26 +++- >> gdb/testsuite/gdb.cp/ref-params.cc | 95 +++++++++++- >> gdb/testsuite/gdb.cp/ref-params.exp | 146 +++++++++++++++++++ >> gdb/testsuite/gdb.cp/rvalue-ref-overload.exp | 1 - >> 4 files changed, 261 insertions(+), 7 deletions(-) >> >> diff --git a/gdb/infcall.c b/gdb/infcall.c >> index dcbae679d07..c4e9605a665 100644 >> --- a/gdb/infcall.c >> +++ b/gdb/infcall.c >> @@ -63,6 +63,8 @@ static bool debug_infcall = false; >> #define INFCALL_SCOPED_DEBUG_START_END(fmt, ...) \ >> scoped_debug_start_end (debug_infrun, "infcall", fmt, ##__VA_ARGS__) >> >> +static CORE_ADDR reserve_stack_space (const type *values_type, CORE_ADDR &sp); >> + >> /* Implement 'show debug infcall'. */ >> >> static void >> @@ -246,7 +248,8 @@ show_unwind_on_timeout_p (struct ui_file *file, int from_tty, >> >> static struct value * >> value_arg_coerce (struct gdbarch *gdbarch, struct value *arg, >> - struct type *param_type, int is_prototyped) >> + struct type *param_type, int is_prototyped, >> + CORE_ADDR *sp, struct thread_info *call_thread) >> { >> const struct builtin_type *builtin = builtin_type (gdbarch); >> struct type *arg_type = check_typedef (arg->type ()); >> @@ -276,10 +279,23 @@ value_arg_coerce (struct gdbarch *gdbarch, struct value *arg, >> return value_cast_pointers (type, arg, 0); >> >> /* Cast the value to the reference's target type, and then >> - convert it back to a reference. This will issue an error >> - if the value was not previously in memory - in some cases >> - we should clearly be allowing this, but how? */ >> + convert it back to a reference. If the value is not already >> + in memory (e.g., a literal), we need to allocate space in the >> + inferior and copy it there. */ >> new_value = value_cast (type->target_type (), arg); >> + if (new_value->lval () != lval_memory >> + && language_pass_by_reference (new_value->type ()) >> + .trivially_copyable) >> + { >> + CORE_ADDR addr; >> + >> + gdb_assert (sp != nullptr); > > Given reserve_stack_space expects a reference to a CORE_ADDR, I think > I'd just make the argument to this function 'CORE_ADDR &sp', then this > assert can be dropped. I will make that change. Thank you again for taking a look at this, Keith