From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31102 invoked by alias); 1 Oct 2014 18:05:44 -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 31089 invoked by uid 89); 1 Oct 2014 18:05:43 -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-f175.google.com Received: from mail-ob0-f175.google.com (HELO mail-ob0-f175.google.com) (209.85.214.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 01 Oct 2014 18:05:41 +0000 Received: by mail-ob0-f175.google.com with SMTP id wn1so813416obc.6 for ; Wed, 01 Oct 2014 11:05:39 -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=5wpDwl+49He14XfjOnRtz4HNyIylw/4w2rtii76IYdI=; b=OrTe/+e2Bry3p/sXGRaI9t4LiCWE339iACAtknVzmfisBJXCa1NT/zfZQGnEBhG3HD k9HfLCPCDMkZnPCrRmXQl7quga9Ut+H9aWcsYMhbrR4PzGSTqGK8aMtR9ccOEeogLmN8 l7WJIRoqIuH+OdU7al6R8274dZpbbVYIjxypkwXwoqZEqgOqvAvJkYURUzSkZn2Dn3uQ Xs5dKbfqlIEu6ZTxt0qatYliD439okkLRJGuGyBYmnfigL32dV5CcDCi1x1S11rtpEAL O+PhDQ0gdanB5LPxvTCuUfxmiXwOw1+xD1C/qHHtE50auaj/kYSZEtbH/TgrP6SWQ/es QC0w== X-Gm-Message-State: ALoCoQkj+641mEfyztmwOfxc6WWnw30+iRqG5jlJCia67e7A0az0T7EKZ6rUXMu7zKk79aRUrMbN MIME-Version: 1.0 X-Received: by 10.60.80.72 with SMTP id p8mr21728155oex.74.1412186739764; Wed, 01 Oct 2014 11:05:39 -0700 (PDT) Received: by 10.202.197.13 with HTTP; Wed, 1 Oct 2014 11:05:39 -0700 (PDT) In-Reply-To: <201410011315.s91DF9Vu030545@d06av02.portsmouth.uk.ibm.com> References: <201410011315.s91DF9Vu030545@d06av02.portsmouth.uk.ibm.com> Date: Wed, 01 Oct 2014 18:05: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/msg00016.txt.bz2 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. Thanks, Siva Chandra