From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21101 invoked by alias); 22 Jan 2004 22:30:21 -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 21093 invoked from network); 22 Jan 2004 22:30:20 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 22 Jan 2004 22:30:20 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AjnLA-0004lW-BJ for ; Thu, 22 Jan 2004 17:30:20 -0500 Date: Thu, 22 Jan 2004 22:30:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [rfa] lookup_transparent_type hack Message-ID: <20040122223020.GB17425@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20040119042535.GA10479@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2004-01/txt/msg00617.txt.bz2 On Thu, Jan 22, 2004 at 02:00:08PM -0800, David Carlton wrote: > On Sun, 18 Jan 2004 23:25:35 -0500, Daniel Jacobowitz said: > > > This is OK. I'd also like to see results with 2.95, though I expect > > no difficulties. > > No problems with 2.95. Unfortunately, there are issues with mainline > GCC. (As of last Thursday's GCC, at least.) The new test in rtti.exp > (print *obj) fails there, and in fact the earlier test in rtti.exp > (print *e2), which I would expect to pass, is KFAILing. > > These failures aren't caused by my patch to GDB - they happen with or > without the patch - but I want to look into the reason for the > behavior first before committing the patch. There are also some > (non-regression) FAILs in namespace.exp that are probably related to > this. (I have a patch waiting for approval that takes care of most of > the FAILs in namespace.exp, but not all of them.) OK. > Am I correct in remembering that GCC has recently changed its rules > for when it emits debug info for classes? Something about only > emitting them in the same place where it emits the vtable (which it > does following the CFront rule)? If so, that might be relevant. Or > am I thinking of something else? Well, I recently had an argument about it, but the behavior is not new - it's done that for years. The only 'recent' change is not to emit debug info for unused types. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer