From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26144 invoked by alias); 20 Jun 2005 08:45:40 -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 26120 invoked by uid 22791); 20 Jun 2005 08:45:29 -0000 Received: from lon-del-02.spheriq.net (HELO lon-del-02.spheriq.net) (195.46.50.98) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 20 Jun 2005 08:45:29 +0000 Received: from lon-out-02.spheriq.net ([195.46.50.130]) by lon-del-02.spheriq.net with ESMTP id j5K8jMQf026633 for ; Mon, 20 Jun 2005 08:45:22 GMT Received: from lon-cus-02.spheriq.net (lon-cus-02.spheriq.net [195.46.50.38]) by lon-out-02.spheriq.net with ESMTP id j5K8iI0N019844 for ; Mon, 20 Jun 2005 08:44:19 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 j5K8jIi1001883 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Mon, 20 Jun 2005 08:45:20 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 0A41ADA5A for ; Mon, 20 Jun 2005 08:45:00 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id AA08B47387; Mon, 20 Jun 2005 08:46:50 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 32B497599B for ; Mon, 20 Jun 2005 08:46:50 +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 E916547387 for ; Mon, 20 Jun 2005 08:46:48 +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 BKJ04091 (AUTH lyon); Mon, 20 Jun 2005 10:44:54 +0200 (CEST) Message-ID: <42B68205.38424254@st.com> Date: Mon, 20 Jun 2005 08:45:00 -0000 From: Christophe LYON MIME-Version: 1.0 To: gdb@sourceware.org Subject: GDB and C++: handling of POD/non-POD objects 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/msg00190.txt.bz2 Hi all, I am working on C++ support in our GDB port, and currently fixing bugs with the handling of how objects are returned by function called "by hand". Our compiler conforms to the common vendor ABI, and I have to distinguish POD and non-POD objects. For the latter, a hidden parameter is supplied by the caller, which is a pointer to a memory area to store the return value. I have looked in GDB how POD and non-POD objects are handled and found only a few lines in the AMD64 port. I have to mention that it looks buggy, as non-POD objects are equivalent to objects which have base classes, which is not the right definition. 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? I guess I will have to write my own code. Regards, Christophe.