From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 4686E3858D1E for ; Mon, 6 May 2024 12:29:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4686E3858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none 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 4686E3858D1E 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=1714998562; cv=none; b=AVjVG8u11HdgzECgBhQbE37ZRa57f7iI864ImGYHmIC8vvfYpF519M55A+mVrvg3TddX3PTzS2qPRm8eajXcmcieBhtNprXKOjvjdIupWnNqIWvQkYw9QscdgPN1WsnnrhdnFjIBrETVXz0mKiawwPdQGV0pqnzX2m4QVRA2FTc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714998562; c=relaxed/simple; bh=SBJtIRZXZwjM0iHpmznI5NXXAxnAUOsLjWhC6zkQBCg=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=f6ZScJWvd6onsKbpw+DDX0DOBT6eukgyLBpqq0gDGb7oZQCet31Lise0GtKSi+3oYCkgp8eolpRssSJLZ98XEGbEfn7TdA4iCKcuu9obN9jIvlmVHfJEwUfSeczgOccO/KClPDkesBwad8/usOKdmMHiRzljuTBVZ6yrEec4bgs= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1714998559; 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=azDd7HT46CAyTpOFCuq857gccMBIyjzmOcq/ft7mWVE=; b=FJ9dsJ35IzCr5luAN7VNAH1WeUvxDHkRPW2qNnSyHickQrpvfVR0O2qqvCz21PbzTYXU19 zvvYKBaAMC5S+wo4MPh7REtswgCB3NECevR9MLjBTXvQ7k4Oij+Es/WuP1AAOZWRkiQ64v JcGmXFS31ESEjfa9oHS++Ov/pPzqOXk= Received: from mail-pj1-f71.google.com (mail-pj1-f71.google.com [209.85.216.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-172-AZDH3dFTPm6LyrZnRGB3tw-1; Mon, 06 May 2024 08:29:18 -0400 X-MC-Unique: AZDH3dFTPm6LyrZnRGB3tw-1 Received: by mail-pj1-f71.google.com with SMTP id 98e67ed59e1d1-2b29f4af4e4so1685155a91.1 for ; Mon, 06 May 2024 05:29:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714998557; x=1715603357; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=azDd7HT46CAyTpOFCuq857gccMBIyjzmOcq/ft7mWVE=; b=R0G8k77FvaAEBdIacjBtnm1Kas8j8Pn6/nyIYgz3JOivPvvfqo2FVYI2aNs+y169YA 4NBa1wzxR60LunNpAYacZdGKFCBn3krAMQSnInBNuDhu8rc0twJAlATJZUPOXkngTtqY rGFicT4vfbiSZZfIRZzEl/AB1/ltDTHZu5RHi6jw3U8ox/VeyjUay73cL61ZT7frRYLL CKFXt+GhUfRmOn1u9v8Fbc9jkYUKgF6i6HFsP0u+uXOZlCrFJcIHYimPGrenCWkUKdf6 Wq90Blr2wDk4m5JZr8pXtMinw64ZR6IQYeJgzBYVJSV+W3nhV5fKywrH8fgv6V+hkulF O/OQ== X-Forwarded-Encrypted: i=1; AJvYcCUT0DPTLv1Ki27l3PYiWU9jK+94jYPOY1uZNACOfK0ptn49N7R68Jj3zUzma/Jk0uUJ0/OMZ6YHpznziYgXg2VS/Tz7alx7X3ZuIA== X-Gm-Message-State: AOJu0Yys29ZaBgdsupZEGzAmmg/j7cUNbmDY7aaY3y4ShPD/UwRa6VRP WyOMjBrN5JqYjjMXW7ruruIBK8kPvuhbFgRiTVL+U37ObsqoRrT89n3QL7J4veFwVW0ei85H1Fy nZwsMD9OjM9nxYV/BcatsPkI9M5jQJCzw48dE86WS4Nsr4DP3dqGVHelvCLc6TNkZnDI= X-Received: by 2002:a17:90b:1e04:b0:2b2:c8f1:92d0 with SMTP id pg4-20020a17090b1e0400b002b2c8f192d0mr8168691pjb.20.1714998556760; Mon, 06 May 2024 05:29:16 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEHbwodCtAnoiy0vYg+r6AL4zGM3s+J3Uz52gLbYeDDH3lCqLhBICQmkATvmzMtuyleJXUMBw== X-Received: by 2002:a17:90b:1e04:b0:2b2:c8f1:92d0 with SMTP id pg4-20020a17090b1e0400b002b2c8f192d0mr8168663pjb.20.1714998556058; Mon, 06 May 2024 05:29:16 -0700 (PDT) Received: from ?IPV6:2804:14d:8084:92c5::1000? ([2804:14d:8084:92c5::1000]) by smtp.gmail.com with ESMTPSA id p14-20020a170902780e00b001e435fa2521sm8353561pll.249.2024.05.06.05.29.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 May 2024 05:29:15 -0700 (PDT) Message-ID: <3bd0a4f2-231f-4d2b-b3dc-8bdfc361a981@redhat.com> Date: Mon, 6 May 2024 09:29:12 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] Allow calling of user-defined function call operators To: Hannes Domani , "gdb-patches@sourceware.org" References: <20240427163606.1780-1-ssbssa.ref@yahoo.de> <20240427163606.1780-1-ssbssa@yahoo.de> <2b1c0466-634d-497c-a2c2-86de6ec85e6c@redhat.com> <875245506.10597907.1714762292467@mail.yahoo.com> From: Guinevere Larsen In-Reply-To: <875245506.10597907.1714762292467@mail.yahoo.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-10.7 required=5.0 tests=BAYES_00,BODY_8BITS,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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: On 5/3/24 15:51, Hannes Domani wrote: > 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      struct S { >>> 2        int operator() (int x) { return x + 5; } >>> 3      }; >>> 4 >>> 5      int main () { >>> 6        S s; >>> 7 >>> 8        return s(23); >>> 9      } >>> (gdb) p s(10) >>> Invalid data type for function to be called. >>> (gdb) p s.operator()(10) >>> $1 = 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 = 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=12213 >>> --- >>> v2: >>> - Move the logic into evaluate_subexp_do_call, to avoid duplication in >>>     every evaluate_funcall of each operation subclass. >>>     This makes it now work for some cases it didn't in v1, like if it's >>>     called on a class member (`print c.m(5)` in the new test). >>> - Added tests for other (struct member) operations. >>> --- >>>   gdb/eval.c                      | 29 ++++++++++++++++++++++++++--- >>>   gdb/testsuite/gdb.cp/userdef.cc  | 22 ++++++++++++++++++++++ >>>   gdb/testsuite/gdb.cp/userdef.exp |  7 +++++++ >>>   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 noside noside, >>>   { >>>     if (callee == NULL) >>>       error (_("Cannot evaluate function -- may be inlined")); >>> + >>> +  type *ftype = callee->type (); >>> + >>> +  /* If the callee is a struct, there might be a user-defined function call >>> +    operator that should be used instead.  */ >>> +  std::vector vals; >>> +  if (overload_resolution >>> +      && exp->language_defn->la_language == language_cplus >>> +      && check_typedef (ftype)->code () == TYPE_CODE_STRUCT) >>> +    { >>> +      vals.resize (argvec.size () + 1); >>> + >>> +      vals[0] = value_addr (callee); >>> +      for (int i = 0; i < argvec.size (); ++i) >>> +    vals[i + 1] = argvec[i]; >>> + >>> +      int static_memfuncp; >>> +      find_overload_match (vals, "operator()", METHOD, &vals[0], nullptr, >>> +              &callee, nullptr, &static_memfuncp, 0, noside); >>> +      if (!static_memfuncp) >>> +    argvec = 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(). Ah, thanks for explaining! I think a comment would be pretty helpful in this situation. > I'm not sure why this would change the logic for the rest of the function. My thinking is that, on some situations for the rest of the function, there may be one too many arguments. To give a concrete example, I thought that if you had foo.bar(), where bar is a regular method, this could be adding the "this" argument one too many times. But that would mean "callee" is 'foo', and re-reading with fresh eyes, callee is supposed to be "bar", right? > > >>> +    } >>> + >>>     if (noside == EVAL_AVOID_SIDE_EFFECTS) >>>       { >>>         /* If the return type doesn't look like a function type, >>>       call an error.  This can happen if somebody tries to turn >>>       a variable into a function call.  */ >>> >>> -      type *ftype = callee->type (); >>> - >>>         if (ftype->code () == TYPE_CODE_INTERNAL_FUNCTION) >>>       { >>>         /* We don't know anything about what the internal >>> @@ -666,9 +687,11 @@ operation::evaluate_funcall (struct type *expect_type, >>>     struct type *type = callee->type (); >>>     if (type->code () == TYPE_CODE_PTR) >>>       type = type->target_type (); >>> +  bool type_has_arguments >>> +    = type->code () == TYPE_CODE_FUNC || type->code () == TYPE_CODE_METHOD; >>>     for (int i = 0; i < args.size (); ++i) >>>       { >>> -      if (i < type->num_fields ()) >>> +      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. > > 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. Ooohh, I see. Again, I think a code comment would help a lot. Something above the if, saying for example:     "If type is a struct, num_fields would refer to the number of members in the type, not the number of arguments" or similar. -- Cheers, Guinevere Larsen She/Her/Hers > > > Hannes >