From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13489 invoked by alias); 28 Jun 2005 13:04:35 -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 13451 invoked by uid 22791); 28 Jun 2005 13:04:24 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 28 Jun 2005 13:04:24 +0000 Received: from drow by nevyn.them.org with local (Exim 4.51) id 1DnFlF-0007KH-DN; Tue, 28 Jun 2005 09:04:21 -0400 Date: Tue, 28 Jun 2005 13:04:00 -0000 From: Daniel Jacobowitz To: Christophe LYON Cc: gdb@sourceware.org Subject: Re: GDB and C++: handling of POD/non-POD objects Message-ID: <20050628130421.GA28098@nevyn.them.org> Mail-Followup-To: Christophe LYON , gdb@sourceware.org References: <42B68205.38424254@st.com> <20050620135706.GA29971@nevyn.them.org> <42B80111.BA626F61@st.com> <42C12B0C.39261B06@st.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42C12B0C.39261B06@st.com> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-06/txt/msg00290.txt.bz2 On Tue, Jun 28, 2005 at 12:48:44PM +0200, Christophe LYON wrote: > > > > 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. What target and compiler is this? This is contrary to the normal interpretation of the ABI. 3.1.4 specifies that it is "an implicit first parameter", which does imply a parameter shift. This makes a substantial difference on ia64; this goes in the first parameter register, instead of in the normal C structure return register. -- Daniel Jacobowitz CodeSourcery, LLC