From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 945 invoked by alias); 1 Oct 2014 13:15:23 -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 927 invoked by uid 89); 1 Oct 2014 13:15:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: e06smtp11.uk.ibm.com Received: from e06smtp11.uk.ibm.com (HELO e06smtp11.uk.ibm.com) (195.75.94.107) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 01 Oct 2014 13:15:20 +0000 Received: from /spool/local by e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 1 Oct 2014 14:15:17 +0100 Received: from d06dlp03.portsmouth.uk.ibm.com (9.149.20.15) by e06smtp11.uk.ibm.com (192.168.101.141) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 1 Oct 2014 14:15:15 +0100 Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 43DA21B08072 for ; Wed, 1 Oct 2014 14:16:27 +0100 (BST) Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id s91DFEIX51445876 for ; Wed, 1 Oct 2014 13:15:14 GMT Received: from d06av02.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s91DFCjK030759 for ; Wed, 1 Oct 2014 07:15:12 -0600 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with SMTP id s91DF9Vu030545; Wed, 1 Oct 2014 07:15:09 -0600 Message-Id: <201410011315.s91DF9Vu030545@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 01 Oct 2014 15:15:08 +0200 Subject: Re: [PATCH 0/2] Make chained function calls in expressions work To: sivachandra@google.com (Siva Chandra) Date: Wed, 01 Oct 2014 13:15:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org (gdb-patches) In-Reply-To: from "Siva Chandra" at Sep 30, 2014 05:42:19 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14100113-5024-0000-0000-0000017F9331 X-SW-Source: 2014-10/txt/msg00012.txt.bz2 > 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). Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com