Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Dan Mosedale <dmose@mozilla.org>
To: Daniel Berlin <dan@cgsoftware.com>
Cc: Daniel Jacobowitz <drow@mvista.com>,
	libstdc++@gcc.gnu.org, gdb@sources.redhat.com
Subject: Re: C++ debugging progress
Date: Wed, 21 Nov 2001 13:37:00 -0000	[thread overview]
Message-ID: <3C054837.6020902@mozilla.org> (raw)
In-Reply-To: <Pine.LNX.4.33.0111280239110.15446-100000@www.cgsoftware.com>

Daniel Berlin wrote:

> Subject:
>
> Re: C++ debugging progress
> From:
>
> Daniel Berlin <dan@cgsoftware.com>
> Date:
>
> Wed, 28 Nov 2001 02:43:43 -0500 (EST)
>
> To:
>
> Daniel Jacobowitz <drow@mvista.com>
> CC:
>
> <libstdc++@gcc.gnu.org>, <gdb@sources.redhat.com>
>
>
>
>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 <tromey at cygnus dot com>
>     * Date: 03 May 2000 09:41:50 -0600
>     * Newsgroups: cygnus.patches.gdb
>     * Organization: Cygnus Solutions
>     * References:
><Pine.LNX.4.10.10005020923450.14281-100000@propylaea.anduin.com>
><npu2ggf8g3.fsf@zwingli.cygnus.com>
>     * 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



WARNING: multiple messages have this Message-ID
From: Dan Mosedale <dmose@mozilla.org>
To: Daniel Berlin <dan@cgsoftware.com>
Cc: Daniel Jacobowitz <drow@mvista.com>,
	libstdc++@gcc.gnu.org, gdb@sources.redhat.com
Subject: Re: C++ debugging progress
Date: Wed, 28 Nov 2001 12:25:00 -0000	[thread overview]
Message-ID: <3C054837.6020902@mozilla.org> (raw)
Message-ID: <20011128122500.OG4nLhyj97k6vDd7S9ljMtV_c4UvRKnh1SNYdle9xrY@z> (raw)
In-Reply-To: <Pine.LNX.4.33.0111280239110.15446-100000@www.cgsoftware.com>

Daniel Berlin wrote:

> Subject:
>
> Re: C++ debugging progress
> From:
>
> Daniel Berlin <dan@cgsoftware.com>
> Date:
>
> Wed, 28 Nov 2001 02:43:43 -0500 (EST)
>
> To:
>
> Daniel Jacobowitz <drow@mvista.com>
> CC:
>
> <libstdc++@gcc.gnu.org>, <gdb@sources.redhat.com>
>
>
>
>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 <tromey at cygnus dot com>
>     * Date: 03 May 2000 09:41:50 -0600
>     * Newsgroups: cygnus.patches.gdb
>     * Organization: Cygnus Solutions
>     * References:
><Pine.LNX.4.10.10005020923450.14281-100000@propylaea.anduin.com>
><npu2ggf8g3.fsf@zwingli.cygnus.com>
>     * 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



  reply	other threads:[~2001-11-28 20:25 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-27 23:03 Daniel Jacobowitz
2001-11-18 21:43 ` Daniel Jacobowitz
2001-11-19  9:04 ` Benjamin Kosnik
2001-11-27 23:36   ` Benjamin Kosnik
2001-11-19 11:16 ` Daniel Berlin
2001-11-21 13:37   ` Dan Mosedale [this message]
2001-11-28 12:25     ` Dan Mosedale
2001-11-27 23:43   ` Daniel Berlin
2001-11-19 13:41 ` Jason Merrill
2001-11-28  1:31   ` Jason Merrill
2001-11-28  9:41   ` Daniel Jacobowitz
2001-11-21  4:12     ` Daniel Jacobowitz
2001-11-21  5:06     ` Daniel Berlin
2001-11-28 10:36       ` Daniel Berlin
2001-11-28 10:49       ` Daniel Jacobowitz
2001-11-21 12:33         ` Daniel Jacobowitz
2001-11-28 11:41     ` Jason Merrill
2001-11-21 13:21       ` Jason Merrill
2001-11-21 13:42       ` Daniel Jacobowitz
2001-11-28 12:32         ` Daniel Jacobowitz
2001-11-21 16:38       ` Jason Merrill
2001-11-22  0:13         ` Daniel Jacobowitz
2001-11-24 22:52           ` Jason Merrill
2001-11-29  9:44             ` Jason Merrill
2001-11-29 12:28             ` Daniel Jacobowitz
2001-11-25  8:34               ` Daniel Jacobowitz
2001-11-25  9:01               ` Kevin Buettner
2001-11-25 10:30                 ` Jason Merrill
2001-11-29 19:12                   ` Jason Merrill
2001-11-29 13:11                 ` Kevin Buettner
2001-11-29 12:50               ` Benjamin Kosnik
2001-11-25  8:40                 ` Benjamin Kosnik
2001-11-28 13:31           ` Daniel Jacobowitz
2001-11-28 13:03         ` Jason Merrill
     [not found]       ` <20011128151819.A31514@nevyn.them.org>
2001-11-21 22:26         ` Jason Merrill
2001-11-28 13:14           ` Jason Merrill

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3C054837.6020902@mozilla.org \
    --to=dmose@mozilla.org \
    --cc=dan@cgsoftware.com \
    --cc=drow@mvista.com \
    --cc=gdb@sources.redhat.com \
    --cc=libstdc++@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox