From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10183 invoked by alias); 6 Aug 2010 16:48:56 -0000 Received: (qmail 10173 invoked by uid 22791); 6 Aug 2010 16:48:55 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_SOFTFAIL,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mtagate3.de.ibm.com (HELO mtagate3.de.ibm.com) (195.212.17.163) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 Aug 2010 16:48:50 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.1/8.13.1) with ESMTP id o76GmlOM025065 for ; Fri, 6 Aug 2010 16:48:47 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o76Gml1B1786034 for ; Fri, 6 Aug 2010 18:48:47 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id o76Gml5A008789 for ; Fri, 6 Aug 2010 18:48:47 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id o76Gmk3o008780; Fri, 6 Aug 2010 18:48:46 +0200 Message-Id: <201008061648.o76Gmk3o008780@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Fri, 06 Aug 2010 18:48:46 +0200 Subject: Re: [patch] smart pointer support To: swagiaal@redhat.com (sami wagiaalla) Date: Fri, 06 Aug 2010 16:48:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <4C5C36F1.9040800@redhat.com> from "sami wagiaalla" at Aug 06, 2010 12:23:13 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2010-08/txt/msg00075.txt.bz2 sami wagiaalla wrote: > Hmm I see. I was under the impression that here the value is copied from > the inferior's return location to gdb memory. As the patch stands (with > the kfail) this can be removed, but I am actually looking for guidance > on how to ensure that this value is available for gdb to perform further > function calls that utilize it, especially when the return value is a > copy not a reference. As is described in this bug: > http://sourceware.org/bugzilla/show_bug.cgi?id=11606 So there's two issues here. The first question is, what can you expect from a GDB value representing the return value of an inferior function call? You will *always* get the value itself, as bytes copied to GDB's memory. In *some* cases, the value will in addition be of type lval_memory meaning that the value is also present in inferior memory, *and you know where*. See existing code: switch (gdbarch_return_value (gdbarch, value_type (function), target_values_type, NULL, NULL, NULL)) { case RETURN_VALUE_REGISTER_CONVENTION: case RETURN_VALUE_ABI_RETURNS_ADDRESS: case RETURN_VALUE_ABI_PRESERVES_ADDRESS: retval = allocate_value (values_type); gdbarch_return_value (gdbarch, value_type (function), values_type, retbuf, value_contents_raw (retval), NULL); break; case RETURN_VALUE_STRUCT_CONVENTION: retval = value_at (values_type, struct_addr); break; } In the second case, we get a lval_memory value including the address ("struct_addr") where it resides. In the first case, we just get a non_lval value because the value doesn't reside in memory in the first place; it was returned in registers. Thinking more about this, the value_at case actually looks broken, because while the value is in memory, that memory slot was just temporarily allocated on the stack, and will go away as soon as we return from call_function_by_hand! So it might in fact be better to just return a non_lval in that case, too ... The second question is: Well, if all we have is a non_lval, can we still call a member function? In priciple we could do the same what C++ does and allocate a temporary copy on the stack; we'd probably want to this at the time we call the member function in call_function_by_hand, similar to how we already create temporary copies of call arguments as required. That seems the way forward to fix the bug you point out ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com