From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25368 invoked by alias); 23 Oct 2014 15:07:48 -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 25356 invoked by uid 89); 23 Oct 2014 15:07:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.6 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-f182.google.com Received: from mail-ob0-f182.google.com (HELO mail-ob0-f182.google.com) (209.85.214.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 23 Oct 2014 15:07:45 +0000 Received: by mail-ob0-f182.google.com with SMTP id uy5so893487obc.13 for ; Thu, 23 Oct 2014 08:07:44 -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=EOkghprADR8Q33yTmjT9v4tziIPb0YFzszStuRJFqWY=; b=BrtKOlZA0vLFAYSZhni1W1wsSpXoTjfh6aiyej340XkKT9PItxum/DvRuPjFQrr5x0 1DkfpyMw+23l7GEfHiETMT2ZqAsf4JcfpMFn7Fzz5UMS+ZZqbC4HGdtzCypCp5xMDd6N k8XyhSC/CYpTUtPJZlr3IqCFH3ErJuu2V4+zGgExTIkKjiF1NY4dqFP8SFQp3cxK/2BX Ut//KFafkq3EkXQ4O2huSIwTY/tRLHncbWVuP/FSVXlqUCdfo4DKzhTkWeV6BPYOeVP4 rlDRwOEl0Jpw7Ilr2V0oWtE5J9MUgxe5BwQuwYY41VxqkD/MT/udEv/kIzesHljl77zm bBGA== X-Gm-Message-State: ALoCoQms1SMUoHtjVyP2jEITYtuCuQfP9IhI/0P36XqS7YLYlZFhsSuEYxCUrdywPxNCuX13TbKs MIME-Version: 1.0 X-Received: by 10.202.1.80 with SMTP id 77mr4355241oib.31.1414076863884; Thu, 23 Oct 2014 08:07:43 -0700 (PDT) Received: by 10.202.197.13 with HTTP; Thu, 23 Oct 2014 08:07:43 -0700 (PDT) In-Reply-To: <201410221659.s9MGxqM0004223@d06av02.portsmouth.uk.ibm.com> References: <201410221659.s9MGxqM0004223@d06av02.portsmouth.uk.ibm.com> Date: Thu, 23 Oct 2014 15:07: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/msg00604.txt.bz2 I agree with everything you have said and listed. I have one last point to make. On Wed, Oct 22, 2014 at 9:59 AM, Ulrich Weigand wrote: > - Do something along the lines of your patch (with the changes already > discussed) to preserve return value temporaries as lval_memory objects > in those cases where they are mandated by the ABI (i.e. for types that > have a non-trivial copy constructor or destructor). Restricting to just those values whose address is returned in a hidden param (per ABI) is OK, but an implementation detail made me to include all types of return values. There are two times when a return value's address is required: 1. When a method is invoked on the return value: GDB has to evaluate the 'this' pointer. This is done in eval.c. 2. When the return value is in turn passed as a parameter to a function expecting a reference: GDB has to evaluate the address of the value and generate a TYPE_CODE_REF value from it. This logic is in 'value_arg_coerce' in infcall.c. For objects returned in registers, having logic to create a copy on the stack for situations like 2 is fine. However, for situations like 1, I do not think there is any way to tell whether one is dealing with an intermediate return value or not. In which case, we are hit by the comment at eval.c:1405. This is the reason why I have return values returned in registers copied on to the stack in my patch. Note that, doing a bit copy of objects returned in registers should be just fine as they do not have non-trivial copy constructors or destructors (if they do, then ABI says that they wont be returned in registers). One way to get around the comment at eval.c:1405 is to make copies of only those objects which are not_lval and which do not have non-trivial copy-ctors or d-tors. The same thing has be to done for 2 anyway if we take this route, meaning that we change the flow in two places (infcall.c and eval.c). If you feel that this is OK, I will take this route. My intention was to keep the existing logic as is for as much as possible. If we keep what I have in my patch, then we only need to change 'value_arg_coerce' in infrun.c (and that too, only to enable passing non-lvalue parameters to functions expecting const-reference arguments).