From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sonic307-54.consmr.mail.ir2.yahoo.com (sonic307-54.consmr.mail.ir2.yahoo.com [87.248.110.31]) by sourceware.org (Postfix) with ESMTPS id 75A8C384AB58 for ; Fri, 3 May 2024 18:51:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 75A8C384AB58 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 75A8C384AB58 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=87.248.110.31 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714762296; cv=none; b=n2gHqlOFouT1jo1iF0qE5ngBb/ZeDPl0Trv80HGEkY03wsKMNmJdRI+N7KQfzgVN6QBXEKfSldNVsN5MxgV2NrmvHycjmcaIacUGfvYMKNp7EcnfJwBs/lGM3K23q9X+OoT2MGw3FvpJZLfREnpMfnAUkiL8DqYz1viuLr4yZpA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714762296; c=relaxed/simple; bh=iCAFty9bL2xlRBdRC0MJV0YOXHqMTDi2yAUwSeab9Z4=; h=DKIM-Signature:Date:From:To:Message-ID:Subject:MIME-Version; b=O6HDWlSvQvrJ9FPBzAmXs5qMkpM+JppTHMax6s778of/p4vK0RexfOS2c2YVsI9q2xvT5opnBfVEF+VpiALSLq+6sdIUsbgBGAWjyEc0H0FfwnHyAd7TD745LWK2QlG6lIVFe4tiMK4GFoUHsU9/B0P9fiF0LKQSHWgLisWXSuw= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s2048; t=1714762293; bh=iCAFty9bL2xlRBdRC0MJV0YOXHqMTDi2yAUwSeab9Z4=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=fiHkaflbKnLUMkL6oU6OyePqYWNzKN257Axrp/okgvZx0AkJlxO483WTlKad5jPm1Sog/E3gO7K/5wYrUsHKNnRghl+uJpQ+db8PlC+BwcgCvRrsjTRA6M38wA9K/BSdjboo5NXyFhsb1ypDOOqyEvEiynVKIkArUYv5OIV4J+vWy8CQHKr+O/pb4EHUaRK4kBzrNU//oNU5J8oM3+WErR7/c1JZBu9Zrhe+oU5UQTXNF8eka0TneumwttT9CTEjrDmTlg5Py/M51ex1hGxnumxsf3pckEnSvNTDf5Db0PMt2ukrpMnoKqSeIRC3AyUNvsxmEUdg6yjBdzcJtcIRwg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1714762293; bh=8Fh32VEnPsyPE3Du+cWdJrCVtoOvTCDUXaG/ihFu9tL=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=FfKZWxkOyyykv3WYptJ/Iaj6TrtZ85vbbpR+TGFIrImiKz0Whac2LlAFSGd/dUAjs4iR7OhhElH1DkqYcPdMXVtU4YEwdgoPfleuOTllRWD+M28Qh6rNXkpqGhVhzr6nKOW4wqvF1N44RO3vAgdKMWWFxfphB//5YhVeyjmjvUiQ3G8TbfPd+7GPKPFgF9n8YqAGY6ZHEu2OT02ZxT3b9wzDV6Z9ODZ1xWN1NoCD+9CBZFdttHmf9Tjm1QFHapSLL4Qc1qcDWcxaT2rZHVZ/nQmG6/q7Q07qsLFCVcr1brSM7CR94YWmU9K1dm2Nse5d+4EO+DBP+GuD619w4SQ/Fg== X-YMail-OSG: L9CgSq8VM1l01_5Z9JPu3gwEMjII6wWq_BYvlD6dMqbzey1vB40QBaW4Qvg4wAP rb1p3r5MFV2umr7TmQgSsTtaJHv3_D_z78CjBmShpSgNbMF3vb9LCxJqhI9j7Lq4QLd1u7JEYdO7 sh5My9ZQDuQGLJcl_ZRIFRxHoj2FtHBKzmcTVoiIy3sM4EKz5rEqHpGUjyxodXaodEOZPNgNMqiz 163NH557opXSnX0kop1kCb__ypca5U2MHqcwDLJ4KuXLK2.s.wZcUJM46uOkBMkDQI8CYaK02rC2 VxLn_nhCul5u_mn2oE9eoA2klnkkweHNa6kQwUumUsaMcMlD6kozdv0KDNevidaoXvuD_AQf9hLT ZBbOl8eqnbzd5iInPKThCTY.lK8nhYA8QWM63nCDdCSlIYNKnlfbnRCtMOa9ERbFo3d9fo.QJZN2 kpZTuvrRKqKAPf2hXV2U6QZ2PcWlAhy9iIp7uin1M0XmBR56935WdL0QpuM4zB5K69196nPVJnxs o.tgtQ86zT3yi3D4Fh7O.3n3wKu7Puitz6UL3tzMqu5pm2IinWbNryHGqCWEsCeRSCoGl2d6wWwc 3yiKP.jmjlPth.EyBDh1sViEbMgBAzKEoLJWzmBeSr6bITn_Tz17NO0ShWGbhJN1YPgnuSNe.WZq 7BgX85KiF_h8BBS5dql8Dv0C1i5FLBVBzvDh_VKDnwWHD2ceH1OnCyctP_GxCNRKxdv_By4nhRES 4tO05LMVPa9XV5fP560UzwjzdwGPTUx_OtxNR0gP9x.c5XK2MgYF7jkqhJSgzhthgAVJyIETpz4L xAA9VYhouhgpf.Jh6nWoMoIWT3uk54us1UZI5OQdbCcIfmVm41eFU4uilU9he6yYfOeiXLuNQA35 jLG647MM.xLN7Xta9f6O33MpVTjfsU2R1a9RmxscnU2WnaowLVsIUy0dNfSVHcGIDLvUwXTtXumF k2HIA6lYnc9yTLdNKIUPVRKNA8bUM9VWnEvdU20Q8uL8huatbODbgvzTqswI56F7MTswTafhDU68 VIMmucLfCU03vjYKEHI8gvShQh9U59wM10F30E9ek0T6tFGtje0gxzHPoqs8PquYGkDkJ0bUTVKX 5ZE4JH3sk.3GRWUjVQox4PRb3Cnq5.ieD1rqUVAk_um3dFuf2.f9lpKpkM7y0bimPBiOhkFAb3Mu ng3R7dAHHvJvle4eMFSIeu4_rMHRGkveymGMRCAQn0QAc8VwXXbCQ1qlgPKUuzaih4a0QCUNlC8m QBpoGNvJKngIY0pxNgQ4Nq3iykL8qcPZ2XrH3dLZbhFkB_NNEP0zRqXhgVabczpTzDuZk_Hl4s0U 2N.oqPGSMGJQ.ESUEsmd3kn4kisMoF8sAhFQ08ArTgCvGBjd1BOY2hwheWBqZn2PTaV57JZmR1Rn ArYiROPZ7HwFUBIu7KxF7gKJEeLTvaNV2oG.2X4BkZuInoyBam1FGHarVLYjy9xfU6DxY5Dq5X_Q BVc7AKICQPw2VMQSBfi7QkTZZmRZc7k_.AEZAD1UX3KECrw4aERL3xVIy8xk4EMAXndxTFa0A0dq QAXNF4gBWyXQGgPFgJatRLTIJepBya.yvwSQZ1fDCS64gl6Xq_szqRKeh.voPKqrE46mp8k9Pzlh 3o.xkx6eQXLerXfjvRAippK1j6FhppoZlFz4QESBB18tzlSRNGn7vg6kY0tnehE0cCFP_lZXEr4A oO5WRFIgCVF5CKYrgGPFU1pCKcMw_Yo4VgEwkdYrVeRVw8jc2oenmSaf2ZcdJC4IBTsRbUx4GMg7 _FQe2rmC7DMDTbGfjDWFvu11tVQ0bYuoLw4Vr_BAzOE0YiNmq0cAj2kkGS6r1kqQW2POJK6DlA.Z ETZCFUkey38qRJ6NXrTueo8X4KRcz3e3qSxNqDE5L4TWM6BeL3YpPTZnBq0xwJ4XReLVzSmpk58K MjBnOSy.O4_PnV1kwnAMYVvl2D1E24Nr5pOR6gIIQrY.0DAJoKG0UP.dJ06BsROqjDRFn3da5k45 Tu_4UHRPba05HqMaJVMAG6C.zHnZ3hiOACSjg.Np0i6Ziz04lvrWfQS7lOUsUpHKxbcaNKYsupwI 9FtN0y0KA9eGx6KRAeiFSUGR3nVcPpXCRgcbWoiS7l5N5hi6aaxBQz6KYJLymHc9NllNpMebDw2I GNx2DYCKPogSRpVeJp7X7W.TMNOzqbm6Wsx1K80.LpG9a1aMwpoyVZQXKCsKdBV5H0iudNXLZWT3 pyYtlPTilTI_NEg-- X-Sonic-MF: X-Sonic-ID: ce1984f3-4f8a-485c-9f2a-0159157eb919 Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.ir2.yahoo.com with HTTP; Fri, 3 May 2024 18:51:33 +0000 Date: Fri, 3 May 2024 18:51:32 +0000 (UTC) From: Hannes Domani To: "gdb-patches@sourceware.org" , Guinevere Larsen Message-ID: <875245506.10597907.1714762292467@mail.yahoo.com> In-Reply-To: <2b1c0466-634d-497c-a2c2-86de6ec85e6c@redhat.com> References: <20240427163606.1780-1-ssbssa.ref@yahoo.de> <20240427163606.1780-1-ssbssa@yahoo.de> <2b1c0466-634d-497c-a2c2-86de6ec85e6c@redhat.com> Subject: Re: [PATCH v2] 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.7 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_MSPIKE_H2,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 Freitag, 3. Mai 2024 um 20:29:47 MESZ hat Guinevere Larsen Folgendes geschrieben: > On 4/27/24 13:36, 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 > > ``` > > > > The change in operation::evaluate_funcall is to make sure the type > > fields are only used for function types, only they use them as the > > argument types. > > > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=3D12213 > > --- > > v2: > > - Move the logic into evaluate_subexp_do_call, to avoid duplication in > >=C2=A0=C2=A0=C2=A0 every evaluate_funcall of each operation subclass. > >=C2=A0=C2=A0=C2=A0 This makes it now work for some cases it didn't in v1= , like if it's > >=C2=A0=C2=A0=C2=A0 called on a class member (`print c.m(5)` in the new t= est). > > - Added tests for other (struct member) operations. > > --- > >=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 | = 29 ++++++++++++++++++++++++++--- > >=C2=A0 gdb/testsuite/gdb.cp/userdef.cc=C2=A0 | 22 ++++++++++++++++++++++ > >=C2=A0 gdb/testsuite/gdb.cp/userdef.exp |=C2=A0 7 +++++++ > >=C2=A0 3 files changed, 55 insertions(+), 3 deletions(-) > > > > diff --git a/gdb/eval.c b/gdb/eval.c > > index 6b752e70635..8d5c354f480 100644 > > --- a/gdb/eval.c > > +++ b/gdb/eval.c > > @@ -588,14 +588,35 @@ evaluate_subexp_do_call (expression *exp, enum no= side noside, > >=C2=A0 { > >=C2=A0=C2=A0=C2=A0 if (callee =3D=3D NULL) > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 error (_("Cannot evaluate function -- may= be inlined")); > > + > > +=C2=A0 type *ftype =3D callee->type (); > > + > > +=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 std::vector vals; > > +=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 (ftype)->code () =3D= =3D TYPE_CODE_STRUCT) > > +=C2=A0=C2=A0=C2=A0 { > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 vals.resize (argvec.size () + 1); > > + > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 vals[0] =3D value_addr (callee); > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for (int i =3D 0; i < argvec.size (); += +i) > > +=C2=A0=C2=A0=C2=A0 vals[i + 1] =3D argvec[i]; > > + > > +=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 argvec =3D vals; > > I don't really understand this change. From what I can see in this > patch, you're just shifting all values in argvec one to the right, to > add the callee address. Wouldn't this necessitate a change in the logic > for the rest of the function? Yes, this adds the 'this' pointer as the first argument for operator(). I'm not sure why this would change the logic for the rest of the function. > > +=C2=A0=C2=A0=C2=A0 } > > + > >=C2=A0=C2=A0=C2=A0 if (noside =3D=3D EVAL_AVOID_SIDE_EFFECTS) > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* If the return type doesn't= look like a function type, > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 call an error.=C2=A0 This can happen if s= omebody tries to turn > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a variable into a function call.=C2=A0 */ > > > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type *ftype =3D callee->type (); > > - > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (ftype->code () =3D=3D TYP= E_CODE_INTERNAL_FUNCTION) > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* We don't know anything abo= ut what the internal > > @@ -666,9 +687,11 @@ operation::evaluate_funcall (struct type *expect_t= ype, > >=C2=A0=C2=A0=C2=A0 struct type *type =3D callee->type (); > >=C2=A0=C2=A0=C2=A0 if (type->code () =3D=3D TYPE_CODE_PTR) > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type =3D type->target_type (); > > +=C2=A0 bool type_has_arguments > > +=C2=A0=C2=A0=C2=A0 =3D type->code () =3D=3D TYPE_CODE_FUNC || type->co= de () =3D=3D TYPE_CODE_METHOD; > >=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=C2=A0=C2=A0 if (i < type->num_fields ()) > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (type_has_arguments && i < type->num= _fields ()) > This change also looks to be unrelated to this patch? It's what I described here: > The change in operation::evaluate_funcall is to make sure the type > fields are only used for function types, only they use them as the > argument types. =C2=A0 Before this patch it didn't matter if it used the field types in the evaluate calls, but since the caller type could now also be a struct, these would be the struct fields types, not function arguments. Hannes