From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sonic305-20.consmr.mail.ir2.yahoo.com (sonic305-20.consmr.mail.ir2.yahoo.com [77.238.177.82]) by sourceware.org (Postfix) with ESMTPS id 2A9CC3858420 for ; Sat, 27 Apr 2024 16:43:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2A9CC3858420 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=yahoo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=yahoo.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2A9CC3858420 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=77.238.177.82 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714236190; cv=none; b=DVWweacRq547wFMxum8nKXLsgJVkF1wmocpe32Z0sSGwT6JXFh+cnSyWI7i9Pmww6r2vbbW24ulVbeiHmOOpmIsTSLGzMqQRKvoAbNBRFeACL8fPD8iZGj1LLFS3wN7GsI7fMChH1YYx/ziNwNv1VKtf/g06qW6kuxwGnwXZQ/4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714236190; c=relaxed/simple; bh=PsOOD3DgoUXmeRNJMfKTXvzbojabBwYExhqJwIiXNKM=; h=DKIM-Signature:Date:From:To:Message-ID:Subject:MIME-Version; b=nOhho3uf9vC9IzlrgfbCsvPM4K/AaDaG0yuLJGUJQju57GsbM4szD6crxQX1LzWjUVOrMttuf2yNiH879rgTgKpzrzjbirUZosN2s5HgMU8MiEDPjJnSswfJDrBGZi6OR7SDNSrabWKHv/jNOoNgSjAP+lGX7S9fxWKoPiPxzjY= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s2048; t=1714236187; bh=PsOOD3DgoUXmeRNJMfKTXvzbojabBwYExhqJwIiXNKM=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=mTEWpNO7R1LxrMxP+qZOAN/OBEAHSJDhwq2DEqXfa5bCNEnSAaj4fjWRZdPK2L66+0/IkfQeFYFJGNHxSN9OPhLd1iVLuA+YbKjcvVYXsVKb2qROZXanuicYANSX24AVXWuOgV2bgARoo8X/23cYuf79DvriY/dVNTXhrkAkkF+yXHR6VfCJMiW1VgPp1kh5jRGhwcSsp4i18qxC6xcs7f5HVbpwfc9htP0dAR0EvzjT0PljeG35F7QdKZj1+fFZZgLyVfmnN0xQx/2urFBZlWmp8zM9OPbNcglyafy62Frct/em4LeQUPo3TnKUEOR7hF4phZa2f13lndpvF5QGwA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1714236187; bh=GsFkSu394wVj0CO45qgIrUt8DKBQeSIMriKB+EQGshb=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=KQa87G4JoLflarhFDObegS+RKb3qBTEkQYcFbIyPxeilW5UPA0NWmZ9T9mAo57+XdhTc5IYEjdEzZH3mDGqwElj8n2HDQOCaI2abU36wIceSNrfms05J2fhvv+/k/G1uNMBQ1u5DCgr7iU7fkpYN9n2P/25nwI7aGCUb9W+0PG/7Hk04JjkOla7T9g2Kwjb/PgGrvFTiBWH1EsDtXTyRis/AEElRXzruMiIDQeS0nvrnGQt3GwYCE6O0VrTSk8cG2dyZC8EqlDp28OC9trQyI2RIMXs9n5LpOsHM4ilrPMe3lTLZ9etwIjPpTbglxzI30alm596xoadEBAT4c+2clQ== X-YMail-OSG: ogyXI5QVM1ldTspCIoW_U16jF15AZwSL80Fx5bkcPGI2mZvU5qYJNK797OFcvwa SZp8RKI..WtSJme2XgXZXW8uPnYrFRmmg09AcMfjRAOkUfxxf7gu9EVRijEi1aMJluccjy.AAxi9 iI1EZU_SWbCb9YOrIg9iWD37YyQozHfDbwsnIIg65AXbAwTpi4udd.DKNLHXi.5bTa7fV4vSG72N dePWmpYfmnoucFA2Ir7zwGTRYnzeOosDog8kAhuOOtyHs2syVG_xSaSUuCIrwkGaLCZvxjOefVCw 0oMU2R.a09bHlLVtyhSCXTy4wtM11wZOw2FpcvWhv0BU4TzjhTBtMf_YCBwDba8hkKy0XzKUEL2H HRZ0RJJO69LE5WT0FqTdMZvY6XX9voFwjQWxeKnTb2dG6JABBHGwgOs4j3KDdX5jbMTl2VYo.Ka0 kIFBUXQJomq9_ua9v_SBQgSf1FQvqgP1AXT3AYGAVM7yvxEyObp.s2MAh6Bgo.4mWy2_pc7lUksw fLxWQ6RlN5Zq9Dk6YtwKcmofRLzPt0WH1yPUcD.wd6SMB6RjJEToC.Bzu.XShEIeDCzq1.uGREcD 7nIX.uJ.PhsedIUk3Y3fMzrEQxBhy6jdgEcZSfy4QQImHjVfKd9x6ZKVnj6QV5B7nigkRAAQYjPn B1N8WADOpTCcFlRunbTf7GnBRanPDygqQqL.qMkY.etskxqIWc5AjR6hUiDTfvU.Uei6ZNlYMOFk 5nK9f9LvFiJ7xFUOCnVmnRyfM3dC_ClKbAmoe6BHfMZTMgLYqFHP2s0OMMjo1HVNZz.JtkIX2mGm 2bl7M.v8Tpk41NjHrNqQfsQ.NjELZq3M5HKFSnNL2cockT1yUu0e5a4uURDmm8Nm2ZKaQMP22akO rB9gE_v700TPYuDpU6RGpjavTGhtWFX23H7ko5MiJ0XVnv20T5t0JMh.DPbi7IAMKjXUpfeTYILT uV3N7a8jy4PWZDG67s39vuIPakbPgddW8dJvHpoKkpZ4CPzy31ZyvxSZDjh8853bppvIVaC4QN0t x1zzPTXme1zIp2rODNFb2.52k8JscpWai8nCL1auUKKDFCXgCXvD1a6sPDlDhbwZVBr7TPQAgGbh SQ4w.q7xb3ZNEI4S.F9IZVvF6_V4vjGUwawW8ofYOVNZr8LMDN6cbH8y8KekTcyxtEzenS8vwu4Q 99UznPZ4zCMuV1Umyj070gFXGE.FuNHCnIci1rHOP5TxU0H0NPV3KxTxn6vfyXOn3Y9qtoCOjC4U lGgrpvVXEHDrYltfePz60KqzN9qfR_3q.jg3YNEEOihrYeMWlS4OKvI1YYrH8ABzL0eEtEv1.4ER 1j6.C1qt7uunpdE2.JAYmUkdQpe1CAhL_ljrcRYHzO7i_LfM4dBk8AIEufhZE5GtxImSg6DkKoyu modfTHFGzg6VdUfZbCRv112iUglR8CRvRufqO_HEaOautvaQIaal.0VX1ZzLGkq69lq8rFFHtefU QHTSeHorWdrb4KjQuNxWJmzxufkT2q6qTyz3tL0zW2nLmzzGpvv_uWuvuUh1WbF_Wqzd6KHcFp94 4eq3dsFdofkMZzSosuN3pT5m_sNfp7XxFlAbnc9yyBdg5V_ugZv.WvuB_mtNNC7Jl3Yq4F9YbSI8 hKnLHzShF4ft7avUKSmQgYFNa8pDSJE34Dx4RHi4DQrPFkdX4fNmzQVo71vaPpFKIxgoSTHGME1o ijEqc_AuxHgMzDR8voYSeSHSDe_x7J4DOu3VwP6P8DvnR5AvulLNKAmmBJEt3Ml.SLvD_FzBLLNr x4230t5G2X..kcwl4LZ3HbK_XXypBAxsJ9dmiFerbdx3jyOI8VDbLO2aYWStUySe4XZxD6_Q15x9 ee3JlmEHHxNMF4_lu_Tk7VspwsBsOD0p9kxYUuM5ZLQZUinAoRhV0.BDmqtsQg3.qDlM2BKC6uv2 07Sfu2Frb3gMeXhQpSY6mgbMBYqjawTghJMijH3lYkD31SkTuHqn6ZFaEQ4gYNaP4LrTvzUHNUxr jA5T4Nj6WWEr7TfKvilWpDH4FNdoIA7kqfXC0fkxbA.At3LSp0B3U8V57cTtk.5.QhkWnmmjWtUh a38ZHIuF2UIP0lqFkvIQAZ9Rp67a2P3_MYCUL6uZcXbw2TLf1OdqGxsJ4RQH_PZeGJqoX4TCvpW5 g1rsB7CW3.wzYo9rdF8d0NGsMMu_R.gxSHuIoR2N4DbbhBOznA069rUu4w7S.MNYa4aOsEHa7LNS IO2YI1E_sgFyspATKpAbJhC4yCQCxiVjlMqV5I2E- X-Sonic-MF: X-Sonic-ID: f6384c3e-def0-4d96-ba96-ab43305de999 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ir2.yahoo.com with HTTP; Sat, 27 Apr 2024 16:43:07 +0000 Date: Sat, 27 Apr 2024 16:43:03 +0000 (UTC) From: Hannes Domani To: "gdb-patches@sourceware.org" , Guinevere Larsen Message-ID: <1734445421.7258219.1714236183866@mail.yahoo.com> In-Reply-To: <28251b39-dda2-4da6-8bb6-2a5d81ef39df@redhat.com> References: <20240421124954.3285-1-ssbssa.ref@yahoo.de> <20240421124954.3285-1-ssbssa@yahoo.de> <28251b39-dda2-4da6-8bb6-2a5d81ef39df@redhat.com> Subject: Re: [PATCH] Allow calling of user-defined function call operators MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.22256 YMailNorrin X-Spam-Status: No, score=-8.1 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Am Donnerstag, 25. April 2024 um 20:34:19 MESZ hat Guinevere Larsen Folgendes geschrieben: > On 4/21/24 09:49, Hannes Domani wrote: > > Currently it's not possible to call user-defined function call > > operators, at least not without specifying operator() directly: > > ``` > > (gdb) l 1 > > 1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struct S { > > 2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int operator() (int x) { re= turn x + 5; } > > 3=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }; > > 4 > > 5=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int main () { > > 6=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 S s; > > 7 > > 8=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return s(23); > > 9=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } > > (gdb) p s(10) > > Invalid data type for function to be called. > > (gdb) p s.operator()(10) > > $1 =3D 15 > > ``` > > > > This now looks if an user-defined call operator is available when > > trying to 'call' a struct value, and calls it instead, making this > > possible: > > ``` > > (gdb) p s(10) > > $1 =3D 15 > > ``` > > > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=3D12213 > > Thanks for this fix, this has been a long time coming. > > I have one, possibly big, question. > > > --- > >=C2=A0 gdb/eval.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | = 46 +++++++++++++++++++++++++++----- > >=C2=A0 gdb/testsuite/gdb.cp/userdef.cc=C2=A0 | 18 +++++++++++++ > >=C2=A0 gdb/testsuite/gdb.cp/userdef.exp |=C2=A0 4 +++ > >=C2=A0 3 files changed, 62 insertions(+), 6 deletions(-) > > > > diff --git a/gdb/eval.c b/gdb/eval.c > > index 6b752e70635..e737774ca28 100644 > > --- a/gdb/eval.c > > +++ b/gdb/eval.c > > @@ -664,14 +664,34 @@ operation::evaluate_funcall (struct type *expect_= type, > > > >=C2=A0=C2=A0=C2=A0 value *callee =3D evaluate_with_coercion (exp, noside= ); > >=C2=A0=C2=A0=C2=A0 struct type *type =3D callee->type (); > > -=C2=A0 if (type->code () =3D=3D TYPE_CODE_PTR) > > -=C2=A0=C2=A0=C2=A0 type =3D type->target_type (); > > -=C2=A0 for (int i =3D 0; i < args.size (); ++i) > > + > > +=C2=A0 /* If the callee is a struct, there might be a user-defined fun= ction call > > +=C2=A0=C2=A0=C2=A0 operator that should be used instead.=C2=A0 */ > > +=C2=A0 if (overload_resolution > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 && exp->language_defn->la_language =3D= =3D language_cplus > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 && check_typedef (type)->code () =3D=3D= TYPE_CODE_STRUCT) > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (i < type->num_fields ()) > > -=C2=A0=C2=A0=C2=A0 vals[i] =3D args[i]->evaluate (type->field (i).type= (), exp, noside); > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 else > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for (int i =3D 0; i < args.size (); ++i= ) > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 vals[i] =3D args[i]->evaluate_with_coerci= on (exp, noside); > > + > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 vals.insert (vals.begin(), value_addr (= callee)); > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int static_memfuncp; > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 find_overload_match (vals, "operator()"= , METHOD, &vals[0], nullptr, > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 &callee, nullptr, &static_memfuncp, 0, noside); > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (static_memfuncp) > > +=C2=A0=C2=A0=C2=A0 vals.erase (vals.begin ()); > > +=C2=A0=C2=A0=C2=A0 } > > +=C2=A0 else > > +=C2=A0=C2=A0=C2=A0 { > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (type->code () =3D=3D TYPE_CODE_PTR) > > +=C2=A0=C2=A0=C2=A0 type =3D type->target_type (); > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for (int i =3D 0; i < args.size (); ++i= ) > > +=C2=A0=C2=A0=C2=A0 { > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (i < type->num_fields ()) > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 vals[i] =3D args[i]->evalua= te (type->field (i).type (), exp, noside); > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 else > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 vals[i] =3D args[i]->evalua= te_with_coercion (exp, noside); > > +=C2=A0=C2=A0=C2=A0 } > > This change had me confused for quite a bit. I couldn't figure out why > the base operation::evaluate_funcall. The problem seems to be that if > command used is something less straightforward, like "print (foo+bar) > (args)", we will use the evaluate_funcall of the operation (in this > case, add_operation) instead of var_value_operation's. Did I understand > it correctly? > > Assuming I did, I don't think this code duplication is the best way to > go. Especially seeing as there are some differences in those functions > already, and if all that it takes to defeat out expression parser is use > (*&foo) or (a + b) (), we probably already have latent bugs in this > area. I don't know how to verify it, though, because I really don't > understand the code differences. > > Ideally, I think the best way would be to put all the code in > var_value_operation::evaluate_funcall, but to do this, you'd need to be > able to find a way to call the resulting var_value_operation's function > from all relevant operations, which is probably a lot. > > Another option is to just park all the logic in > operation::evaluate_funcall, so we're always using the correct function. > This comes with the cost of being very confusing in a couple of months > to a year. > > Does this make sense? Yes, it does. And it turns out my patch already didn't work if you e.g. try to use the operator() on struct members. Not sure why I didn't see this before, but all evaluate_funcall variations call evaluate_subexp_do_call at the end, so I just moved the logic there in this v2: https://sourceware.org/pipermail/gdb-patches/2024-April/208663.= html Hannes