From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4569 invoked by alias); 11 Jan 2004 04:10:15 -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 4557 invoked from network); 11 Jan 2004 04:10:10 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 11 Jan 2004 04:10:10 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AfWvR-000485-NL; Sat, 10 Jan 2004 23:10:09 -0500 Date: Sun, 11 Jan 2004 04:10:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] Classify non-POD struct types more or less correctly on AMD64 Message-ID: <20040111041009.GA15714@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb-patches@sources.redhat.com References: <200401101800.i0AI0Zm6026623@elgar.kettenis.dyndns.org> <20040110183622.GA8108@nevyn.them.org> <200401101858.i0AIwdhk032901@elgar.kettenis.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200401101858.i0AIwdhk032901@elgar.kettenis.dyndns.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-01/txt/msg00270.txt.bz2 On Sat, Jan 10, 2004 at 07:58:39PM +0100, Mark Kettenis wrote: > 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. Let's see. gcc/config/i386/i386.c:ix86_return_in_memory: if (TARGET_64BIT) return !examine_argument (mode, type, 1, &needed_intregs, &needed_sseregs); So an argument will be passed in memory if examine_argument returns 0. examine_argument: int n = classify_argument (mode, type, class, 0); if (!n) return 0; for (n--; n >= 0; n--) switch (class[n]) case X86_64_X87_CLASS: case X86_64_X87UP_CLASS: if (!in_return) return 0; break; If any of the classes are X87_CLASS or X87UP_CLASS and !in_return, the argument will be returned in memory. But in_return is the third argument, always 1 in this case. So only if classify_argument returns 0 would a structure be returned in memory. Looking at that function it looks like it will even return some classes with baseclasses in registers. I won't excerpt it here, as it's quite large. But it iterates over the baseclasses. If none of them are larger than 16 bytes (a given, if the derived class isn't larger than 16 bytes) or of a variable size (C++ classes are never variably sized I don't think) or of TFmode/TCmode (128-bit long doubles), I believe that the aggregate will be returned in registers. IOW it doesn't look to me as if GCC implements the non-POD rule. You might wish to try returning a simple non-POD derived class and see what GCC generates. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer