From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24407 invoked by alias); 11 Nov 2014 15:21:21 -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 24387 invoked by uid 89); 11 Nov 2014 15:21:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,RP_MATCHES_RCVD,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: e31.co.us.ibm.com Received: from e31.co.us.ibm.com (HELO e31.co.us.ibm.com) (32.97.110.149) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 11 Nov 2014 15:21:19 +0000 Received: from /spool/local by e31.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 11 Nov 2014 08:21:17 -0700 Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e31.co.us.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 11 Nov 2014 08:21:14 -0700 Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 912EE1FF003E for ; Tue, 11 Nov 2014 08:09:58 -0700 (MST) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id sABFLDFA57868452 for ; Tue, 11 Nov 2014 16:21:13 +0100 Received: from d03av02.boulder.ibm.com (localhost [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id sABFLDTD008841 for ; Tue, 11 Nov 2014 08:21:13 -0700 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d03av02.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with SMTP id sABFLAQ5008463; Tue, 11 Nov 2014 08:21:10 -0700 Message-Id: <201411111521.sABFLAQ5008463@d03av02.boulder.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 11 Nov 2014 16:21:07 +0100 Subject: Re: [PATCH v4] Make chained function calls in expressions work To: sivachandra@google.com (Siva Chandra) Date: Tue, 11 Nov 2014 15:21:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org (gdb-patches) In-Reply-To: from "Siva Chandra" at Nov 11, 2014 07:00:15 AM 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: 14111115-8236-0000-0000-000006D5419F X-SW-Source: 2014-11/txt/msg00185.txt.bz2 Siva Chandra wrote: > On Tue, Nov 11, 2014 at 6:55 AM, Siva Chandra wrote: > > On Tue, Nov 4, 2014 at 7:40 AM, Ulrich Weigand wrote: > >>> Shall I go with the thread route then? > >> > >> Yes, please. Sorry for asking for extra work, but I think overall this > >> will be the better implementation. > > > > I spent some time looking into how this can be done. While I do think > > it can be done (and should be fairly straight forward), it seemed to > > me that it would be more appropriate to cache the temporaries on the > > "selected frame". WDYT? > > Or, current frame? Selected frame would be wrong (if the user selected a frame up the stack). Current frame would be OK, I guess, but it doesn't seem straightforward to do so. Note that frame structs are transient and do not survive running the inferior; once the inferior is restarted (even just for an inferior call), all frame structs are freed and will be recreated once the inferior stops again. (That's why you use frame_id's and not just struct frame pointers if you want to refer to a frame for longer.) This makes struct frame mostly unsuitable to cache additional info. The most cleanly "correct" solution would probably be to cache the temporaries on the *dummy frame*, because that is the frame associated with all the GDB-generated content on the stack, and the dummy_frame struct does persist a bit longer than the frame struct. However, getting there would still be a bit more difficult, since we'd first have to arrange for a dummy frame to persist over multiple inferior call invocations. Currently, the dummy frame is automatically popped in infrun as soon as the call returns. If you want to have a look into that, that would certainly be fine with me, but it is not a requirement. Adding the info to the thread struct should be straightforward and would be fine with me. > > I promise I will not ask any more question after this; I will just > > shut up and do whatever you prefer here. No, please go ahead and ask questions; it's always better to hash the main direction out before spending a lot of time on implementating something ... :-) Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com