From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13952 invoked by alias); 21 Jun 2005 11:59:34 -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 13944 invoked by uid 22791); 21 Jun 2005 11:59:31 -0000 Received: from fra-del-02.spheriq.net (HELO fra-del-02.spheriq.net) (195.46.51.98) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 21 Jun 2005 11:59:31 +0000 Received: from fra-out-03.spheriq.net (fra-out-03.spheriq.net [195.46.51.131]) by fra-del-02.spheriq.net with ESMTP id j5LBxSIQ013438 for ; Tue, 21 Jun 2005 11:59:28 GMT Received: from fra-cus-01.spheriq.net (fra-cus-01.spheriq.net [195.46.51.37]) by fra-out-03.spheriq.net with ESMTP id j5LBwoAq019843 for ; Tue, 21 Jun 2005 11:58:51 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by fra-cus-01.spheriq.net with ESMTP id j5LBxLWF024734 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 21 Jun 2005 11:59:22 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 16079DA41; Tue, 21 Jun 2005 11:59:17 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id 3F73747456; Tue, 21 Jun 2005 12:01:08 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id E0CB87599B; Tue, 21 Jun 2005 12:01:07 +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 D5FB447456; Tue, 21 Jun 2005 12:01:06 +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 BKP02981 (AUTH lyon); Tue, 21 Jun 2005 13:59:13 +0200 (CEST) Message-ID: <42B80111.BA626F61@st.com> Date: Tue, 21 Jun 2005 11:59:00 -0000 From: Christophe LYON MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb@sourceware.org Subject: Re: GDB and C++: handling of POD/non-POD objects References: <42B68205.38424254@st.com> <20050620135706.GA29971@nevyn.them.org> 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/msg00193.txt.bz2 Daniel Jacobowitz wrote: > > On Mon, Jun 20, 2005 at 10:44:53AM +0200, Christophe LYON wrote: > > [...] > > > > I am surprised that no other target already has > > code to handle this: is it because every other > > target always needs the hidden pointer parameter > > to handle object return, whether POD or non-POD? > > The code in the AMD64 port is for a different purpose. What you're > describing needs to live at a higher level, in the architecture > independent code. That's what I was expected, and why I was surprised not to find it. > 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. > OK thanks, we try to include it in our developments. Best regards, Christophe.