From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26279 invoked by alias); 28 Nov 2001 20:25:47 -0000 Mailing-List: contact gdb-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 26247 invoked from network); 28 Nov 2001 20:25:44 -0000 Received: from unknown (HELO netscape.com) (205.217.237.47) by hostedprojects.ges.redhat.com with SMTP; 28 Nov 2001 20:25:44 -0000 Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id fASKPix23461 for ; Wed, 28 Nov 2001 12:25:44 -0800 (PST) Received: from obob.netscape.com ([207.200.73.215]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GNJ22U00.47Q for ; Wed, 28 Nov 2001 12:25:43 -0800 Received: from mozilla.org ([64.236.139.254]) by obob.netscape.com (Netscape Messaging Server 4.15) with ESMTP id GNJ21J00.OQA; Wed, 28 Nov 2001 12:24:55 -0800 Message-ID: <3C054837.6020902@mozilla.org> Date: Wed, 21 Nov 2001 13:37:00 -0000 From: Dan Mosedale User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6+) Gecko/20011127 Netscape6/6.1b1 X-Accept-Language: en-us MIME-Version: 1.0 To: Daniel Berlin CC: Daniel Jacobowitz , libstdc++@gcc.gnu.org, gdb@sources.redhat.com Subject: Re: C++ debugging progress References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2001-11/txt/msg00214.txt.bz2 Daniel Berlin wrote: > Subject: > > Re: C++ debugging progress > From: > > Daniel Berlin > Date: > > Wed, 28 Nov 2001 02:43:43 -0500 (EST) > > To: > > Daniel Jacobowitz > CC: > > , > > > >On Wed, 28 Nov 2001, Daniel Jacobowitz wrote: > >>> For the curious, I've gotten all but two of the virtual function tests to >>> pass in virtfuncs.exp. I'm not entirely sure what's wrong with one of the >>> others, and the other goes up as far as the parser (pEe->D::fd() yields >>> "attempt to take address of value not in memory"). There's also a bunch of >>> namespace problems, of course. >>> >>> I'll not be posting the patches for another day or two. The way I do it now >>> is grossly inefficient; I look through RTTI at every lookup instead of once >>> per type. It also depends on presence of RTTI. There's not much I can do >>> about that - or rather, I could, but AFAICT it would require walking the >>> inheritance graph in the proper order and I don't have the machinery to do >>> that easily. I'm not heartbroken that we need RTTI for debugging though. >> > >Nor am I. >However: > * To: gdb-patches at sources dot redhat dot com > * Subject: Re: Using typeinfo functions to determine RTTI > * From: Tom Tromey > * Date: 03 May 2000 09:41:50 -0600 > * Newsgroups: cygnus.patches.gdb > * Organization: Cygnus Solutions > * References: > > > * Reply-To: tromey at cygnus dot com > (This was me): > >> Does anyone mind if i use the typeinfo name, rather than > >> the virtual table name, to figure out th real type of an object? It > >> only matters if someone does -fno-rtti, i believe. But I have no > >> idea how many people actually use that flag to save time/space in > >> debugging executables. > > Jim> Almost all of Cygnus's customers use GDB to debug embedded apps, > Jim> and space is often an issue there. But I don't actually know how > Jim> many of them use -fno-rtti. > > All Java programs are compiled with -fno-rtti. This includes the C++ > component. So presumably if this change is made it will make it even > harder for me to debug libgcj. > This would also be unfortunate for Mozilla, which compiles -fno-rtti. Debugging Mozilla using gdb is already extremely memory intensive, and being required to use RTTI would make it even worse. :-/ Dan From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Mosedale To: Daniel Berlin Cc: Daniel Jacobowitz , libstdc++@gcc.gnu.org, gdb@sources.redhat.com Subject: Re: C++ debugging progress Date: Wed, 28 Nov 2001 12:25:00 -0000 Message-ID: <3C054837.6020902@mozilla.org> References: X-SW-Source: 2001-11/msg00321.html Message-ID: <20011128122500.OG4nLhyj97k6vDd7S9ljMtV_c4UvRKnh1SNYdle9xrY@z> Daniel Berlin wrote: > Subject: > > Re: C++ debugging progress > From: > > Daniel Berlin > Date: > > Wed, 28 Nov 2001 02:43:43 -0500 (EST) > > To: > > Daniel Jacobowitz > CC: > > , > > > >On Wed, 28 Nov 2001, Daniel Jacobowitz wrote: > >>> For the curious, I've gotten all but two of the virtual function tests to >>> pass in virtfuncs.exp. I'm not entirely sure what's wrong with one of the >>> others, and the other goes up as far as the parser (pEe->D::fd() yields >>> "attempt to take address of value not in memory"). There's also a bunch of >>> namespace problems, of course. >>> >>> I'll not be posting the patches for another day or two. The way I do it now >>> is grossly inefficient; I look through RTTI at every lookup instead of once >>> per type. It also depends on presence of RTTI. There's not much I can do >>> about that - or rather, I could, but AFAICT it would require walking the >>> inheritance graph in the proper order and I don't have the machinery to do >>> that easily. I'm not heartbroken that we need RTTI for debugging though. >> > >Nor am I. >However: > * To: gdb-patches at sources dot redhat dot com > * Subject: Re: Using typeinfo functions to determine RTTI > * From: Tom Tromey > * Date: 03 May 2000 09:41:50 -0600 > * Newsgroups: cygnus.patches.gdb > * Organization: Cygnus Solutions > * References: > > > * Reply-To: tromey at cygnus dot com > (This was me): > >> Does anyone mind if i use the typeinfo name, rather than > >> the virtual table name, to figure out th real type of an object? It > >> only matters if someone does -fno-rtti, i believe. But I have no > >> idea how many people actually use that flag to save time/space in > >> debugging executables. > > Jim> Almost all of Cygnus's customers use GDB to debug embedded apps, > Jim> and space is often an issue there. But I don't actually know how > Jim> many of them use -fno-rtti. > > All Java programs are compiled with -fno-rtti. This includes the C++ > component. So presumably if this change is made it will make it even > harder for me to debug libgcj. > This would also be unfortunate for Mozilla, which compiles -fno-rtti. Debugging Mozilla using gdb is already extremely memory intensive, and being required to use RTTI would make it even worse. :-/ Dan