From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 490 invoked by alias); 10 Jan 2004 18:59:13 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 479 invoked from network); 10 Jan 2004 18:59:12 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.115.144) by sources.redhat.com with SMTP; 10 Jan 2004 18:59:12 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i0AIwejv004747; Sat, 10 Jan 2004 19:58:40 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i0AIweLA032904; Sat, 10 Jan 2004 19:58:40 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6/Submit) id i0AIwdhk032901; Sat, 10 Jan 2004 19:58:39 +0100 (CET) Date: Sat, 10 Jan 2004 18:59:00 -0000 Message-Id: <200401101858.i0AIwdhk032901@elgar.kettenis.dyndns.org> From: Mark Kettenis To: drow@mvista.com CC: gdb-patches@sources.redhat.com In-reply-to: <20040110183622.GA8108@nevyn.them.org> (message from Daniel Jacobowitz on Sat, 10 Jan 2004 13:36:22 -0500) Subject: Re: [PATCH] Classify non-POD struct types more or less correctly on AMD64 References: <200401101800.i0AI0Zm6026623@elgar.kettenis.dyndns.org> <20040110183622.GA8108@nevyn.them.org> X-SW-Source: 2004-01/txt/msg00267.txt.bz2 Date: Sat, 10 Jan 2004 13:36:22 -0500 From: Daniel Jacobowitz On Sat, Jan 10, 2004 at 07:00:35PM +0100, Mark Kettenis wrote: > This (together with the previous patch) fixes the problems I saw with > gdb.cp/bs15503.exp. The check for non-POD-ness isn't complete though. > I hope to revisit that later, after someone tells me how to properly > determine non-POD-ness. > > Mark > > P.S. The amd64_non_pod_p function should probably be moved to the > generic cod, but we can do that later. Does the x86-64 ABI really pass non-POD and POD types of the same size differently? If so, I hope the ABI defines non-POD rather than relying on the C++ definition, since we do not generally have enough information in the debug info to determine whether a type is POD. Oh joy, the ABI doesn't define POD-ness. There's just a footnote which says: The term POD is from the ANSI/ISO C++ Standard, and stands for Plain Old Data. Although the exact definition is technical, a POD is essentially a structure or union that could have been written in C; there cannot be any member functions, or base classes, or similar C++ extensions. And yes, GCC really does pass them differently for aggregates up to 16 bytes in size. > + /* ??? A class with a base class certainly isn't POD, but does this > + catch all non-POD structure types? */ > + if (TYPE_CODE (type) == TYPE_CODE_STRUCT && TYPE_N_BASECLASSES (type) > 0) > + return 1; No, at least any type with explicitly declared methods is non-POD. For DWARF you can probably get this right by checking for a non-artificial method but for stabs you're SOL. Tried that, and a lot of testcases started FAILing. Apparently GCC thinks differently. In userdef.cc, we have a "class A1" with explicitly declared methods, but GCC returns instances of "class A1" in registers nevertheless. Looks like we can't do very much about it. Fortunately most real-life classes will be larger than 16 bytes. Mark