From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17408 invoked by alias); 28 Jun 2005 10:49:19 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 17202 invoked by uid 22791); 28 Jun 2005 10:48:53 -0000 Received: from lon-del-03.spheriq.net (HELO lon-del-03.spheriq.net) (195.46.50.99) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 28 Jun 2005 10:48:53 +0000 Received: from lon-out-03.spheriq.net ([195.46.50.131]) by lon-del-03.spheriq.net with ESMTP id j5SAmp06013934 for ; Tue, 28 Jun 2005 10:48:51 GMT Received: from lon-cus-02.spheriq.net (lon-cus-02.spheriq.net [195.46.50.38]) by lon-out-03.spheriq.net with ESMTP id j5SAmQJn014528 for ; Tue, 28 Jun 2005 10:48:26 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-02.spheriq.net with ESMTP id j5SAmm9G012077 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 28 Jun 2005 10:48:49 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id A731BDA42; Tue, 28 Jun 2005 10:48:47 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id B4C91473D1; Tue, 28 Jun 2005 10:50:41 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 5C28975994; Tue, 28 Jun 2005 10:50:41 +0000 (UTC) Received: from mail2.gnb.st.com (mail2.gnb.st.com [164.129.119.59]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id D950747346; Tue, 28 Jun 2005 10:50:40 +0000 (GMT) Received: from st.com (pcx0003.gnb.st.com [164.129.118.67]) by mail2.gnb.st.com (MOS 3.4.4-GR) with ESMTP id BLP02831 (AUTH lyon); Tue, 28 Jun 2005 12:48:45 +0200 (CEST) Message-ID: <42C12B0C.39261B06@st.com> Date: Tue, 28 Jun 2005 10:49:00 -0000 From: Christophe LYON MIME-Version: 1.0 To: Daniel Jacobowitz , gdb@sourceware.org Subject: Re: GDB and C++: handling of POD/non-POD objects References: <42B68205.38424254@st.com> <20050620135706.GA29971@nevyn.them.org> <42B80111.BA626F61@st.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-O-General-Status: No X-O-Spam1-Status: Not Scanned X-O-Spam2-Status: Not Scanned X-O-URL-Status: Not Scanned X-O-Virus1-Status: No X-O-Virus2-Status: Not Scanned X-O-Virus3-Status: No X-O-Virus4-Status: No X-O-Virus5-Status: Not Scanned X-O-Image-Status: Not Scanned X-O-Attach-Status: Not Scanned X-SpheriQ-Ver: 2.2.1 X-SW-Source: 2005-06/txt/msg00286.txt.bz2 > > Here's a patch; I haven't updated or tested it in a while. I need to > > rework it, and I need to check a couple of existing disabled tests that > > it probably affects; I just haven't had the time yet. > > I have managed to include your patch in our gdb-6.1 source tree. However, I had to remove parts of the infcall.c patch, namely: + if (cp_struct_return) + { + struct value **new_args; + + /* Add the new argument to the front of the argument list. */ + new_args = xmalloc (sizeof (struct value *) * (nargs + 1)); + new_args[0] = value_from_pointer (lookup_pointer_type (value_type), + struct_addr); + memcpy (&new_args[1], &args[0], sizeof (struct value *) * nargs); + args = new_args; + nargs++; + args_cleanup = make_cleanup (xfree, args); + } + else + args_cleanup = make_cleanup (null_cleanup, NULL); (along with the declaration and cleanup of args_cleanup) Indeed, for our target, the pointer to the memory area reserved to hold the return value is passed as a hidden pointer, before 'this', but it does not make all the parameters shift. >From what I found in the C++ abi, 3.1.4, the return value is passed in an implicit hidden pointer, so I guess we are right, and the code above is incorrect. Finally, I have not yet taken time to add true tests to the empty pass-by-ref.exp you supplied. Thanks for you help, Christophe