From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19672 invoked by alias); 10 Jan 2002 20:59:47 -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 19630 invoked from network); 10 Jan 2002 20:59:45 -0000 Received: from unknown (HELO prospero.cambridge.redhat.com) (62.30.164.150) by sources.redhat.com with SMTP; 10 Jan 2002 20:59:45 -0000 Received: (from jason@localhost) by prospero.cambridge.redhat.com (8.11.6/8.11.6) id g0AKxSk09881; Thu, 10 Jan 2002 20:59:28 GMT X-Authentication-Warning: localhost.localdomain: jason set sender to jason@redhat.com using -f To: gdb@sources.redhat.com Cc: Jason Merrill Subject: Re: gdb.c++ failures References: <20020110145303.C9479@nevyn.them.org> From: Jason Merrill In-Reply-To: <20020110145303.C9479@nevyn.them.org> (Daniel Jacobowitz's message of "Thu, 10 Jan 2002 14:53:03 -0500") Date: Thu, 10 Jan 2002 12:59:00 -0000 Message-ID: User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-01/txt/msg00108.txt.bz2 >>>>> "Daniel" == Daniel Jacobowitz writes: > On Thu, Jan 10, 2002 at 01:17:56PM +0000, Jason Merrill wrote: >> classes.exp: dwarf2 doesn't provide mangled names for abstract >> constructors, and there is a difference of opinion between the >> demangler and c-typeprint.c as to whether the type should be written "A >> const &" or "const A &". The demangler always puts the cv-qualifier >> after the type it affects, whereas gdb puts it in front whenever that >> would have the correct meaning. Either one could be changed to match >> the other, or the testcase could be modified to accept either form. >> Thoughts? > The demangler should be left alone and the type printer updated, as far > as I'm concerned - preferably to the GCC3 demangler style. Works for me. >> Also, gdb is including artificial arguments in the printed >> representation of the constructors for vB-vD. The dwarf2 output >> indicates that they are artificial; gdb should not print them. There >> doesn't seem to be a simple way to handle this in the current gdb data >> structures. > What artificial arguments? Or do you mean with GCC 2.95, where these > tests are XFAILd because of this? With dwarf2, the in-class abstract declaration of the constructor has artificial parms for "in charge" and the VTT pointer. The "in charge" parameter is specialized away in both clones, and the VTT is is specialized away in one of them, but both should be represented in the debug info, ideally with DW_AT_const_value attributes where they have been specialized. >> cplusfuncs.exp: cp-demangle bug. The code to handle demangling >> pointers-to-functions isn't complex enough. > OK. Would you mind marking the overly simplistic result as an XFAIL > (or do you anticipate it being fixed soon?) Will do. >> method.exp: The 'print this' tests are failing because gdb is printing >> the types as, say, (A * const), and the test just wants (A *). The >> former is correct, since 'this' is readonly. Any objection to changing >> the test (and others affected) to allow the const? > The standard, or at least Stroustrop seems to disagree - this came up > yesterday on gdb-patches. He claims it should be A *, but not > changeable. I don't care. Stroustrup is right; for whatever reason, the language specifies that 'this' is not an lvalue, so not only is it immutable, but you can't take its address either. I think it's more useful for the debugging information to point at the hidden parameter used to pass the value of 'this' into the function, for which A*const is a perfectly sensible type. Jason