From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9083 invoked by alias); 1 Oct 2014 18:26:03 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 9072 invoked by uid 89); 1 Oct 2014 18:26:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ob0-f176.google.com Received: from mail-ob0-f176.google.com (HELO mail-ob0-f176.google.com) (209.85.214.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 01 Oct 2014 18:26:00 +0000 Received: by mail-ob0-f176.google.com with SMTP id vb8so841787obc.21 for ; Wed, 01 Oct 2014 11:25:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1c/SD/nomZoob6Y0KY4h/wNfhNfnJ3UNvf+RZPpouLM=; b=SVxIbcSwyD+pwICmP38DN41k1IQdHWNxURXvNNp10mNMJvNd61xX0Nwqf36N7fMSgm klW1meBPDpaSGSwcU8LS2zAT/bTpISo0+//wXWnk1Wu9SY3GrHiQAilIYFcMQy78CALV lUvgzYq5uzx0eAg5Sz2a9kL0TdYxrATgx+DFFN6aAMVkpKidMFs9SQRvbgPgDDvTSgrf rV+NeDFUJykawFhxy5P/SjldhcnRPAzA3BMXvSO5GWY8iKMAFStYcWI7urFyin95pvbe B/h2C4IsjvV8daEsKWqr7OO5/Z6NouczYip34O/L8RBYXcaP1kr3+GsMVOqfzglngm6/ l1vg== X-Gm-Message-State: ALoCoQkEJ8O+5MdCpfGwmMICrRFl+PNzdxSrjZULYZvxP4BgANjbTj8uiBuYmzJz0AgQbTnI6JgE MIME-Version: 1.0 X-Received: by 10.60.179.163 with SMTP id dh3mr59722094oec.42.1412187958743; Wed, 01 Oct 2014 11:25:58 -0700 (PDT) Received: by 10.202.197.13 with HTTP; Wed, 1 Oct 2014 11:25:58 -0700 (PDT) In-Reply-To: References: <201410011315.s91DF9Vu030545@d06av02.portsmouth.uk.ibm.com> Date: Wed, 01 Oct 2014 18:26:00 -0000 Message-ID: Subject: Re: [PATCH 0/2] Make chained function calls in expressions work From: Siva Chandra To: Ulrich Weigand Cc: gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00019.txt.bz2 On Wed, Oct 1, 2014 at 11:05 AM, Siva Chandra wrote: > On Wed, Oct 1, 2014 at 6:15 AM, Ulrich Weigand wrote: >>> On Fri, Sep 26, 2014 at 6:29 AM, Siva Chandra wrote: >>> > This patch series enables having chained function calls in >>> > expressions. An example of a chained function call is shown in PR >>> > c++/11606. It has an example of a chain of two function calls. This >>> > patch series enables chains of any number of function calls. >>> > >>> > Currently, an inferior function call is handled via >>> > call_function_by_hand. The value returned by the inferior function is >>> > copied into a GDB value whose lval_type is not_lval. Its contents are >>> > stored within the value irrespective of whether the return value is in >>> > inferior memory or in a register. Consequently, any subsequent >>> > function call in the expression which requires this value's address as >>> > an argument throws an error as the value is not in inferior memory. >>> > >>> > This patch series keeps most of the current flow intact, except that >>> > the value returned by the inferior function is made to be a new >>> > lval_type called lval_mirrored_on_inferior_stack. These values have a >>> > mirrored value of lval_type lval_memory which reside on the inferior >>> > stack. They reside on the stack only for the duration for which the >>> > expression is evaluated. This enables value_address to return the >>> > address of the stack mirror instead of throwing an error. >> >> I'm wondering if there isn't a simpler way to solve this issue: couldn't >> you instead during preparation of the second call_function_by_hand simply >> allocate extra space on the stack and copy not_lval values whose address >> needs to be taken there? This would avoid adding the new lval type, all >> the extra state to track mirrored values during an expression, and would >> actually allow you to pass *other* not_lval values to inferior calls too >> (not just those originating from another inferior call). > > I did think about this route. However, look at the comment at > eval.c:1405. It has an argument for why we should not in general copy > function args on to the stack. > > My patches here target return values of functions. Though return > values end up being function arguments in a chained function call > expression, IMO return values do not suffer from the same problem > pointed to in the comment from above. > > 1. If a function returns a reference, creating a copy of the reference > on the stack and passing it around for the duration the expression is > being evaluated should not be a problem. > 2. If a function returns a value, then it is either returned on the > stack or in a register. My patches do not really disturb the case of a > value being returned on stack. Even when values are returned in > registers, intermediate return values are only temporaries and holding > onto their addresses in some stateful entity will be an error. A tangential point, GDB does not call destructors on these temporaries which IMO is an error. That is why, in my 2/2, you will notice that the expression's state is holding onto all the return value temporaries in a vector instead of just the last one created; In a future pass, I would like to implement invoking the destructors on these temporaries after the expression result is evaluated. Thanks, Siva Chandra