From: Eli Zaretskii <eliz@delorie.com>
To: dberlin@redhat.com
Cc: per@bothner.com, ac131313@cygnus.com, gdb@sources.redhat.com
Subject: Re: C++ FAIL counts and the effect of demangler fix
Date: Fri, 16 Feb 2001 02:32:00 -0000 [thread overview]
Message-ID: <200102161032.FAA04544@indy.delorie.com> (raw)
In-Reply-To: <x7wvarj994.fsf@dynamic-addr-83-177.resnet.rochester.edu>
> From: Daniel Berlin <dberlin@redhat.com>
> Date: 16 Feb 2001 03:57:11 -0500
>
> Eli Zaretskii <eliz@delorie.com> writes:
>
> > > From: Per Bothner <per@bothner.com>
> > > Date: 15 Feb 2001 13:54:02 -0800
> > >
> > > Andrew Cagney <ac131313@cygnus.com> writes:
> > >
> > > > o I don't want GDB's release schedule in
> > > > someway directly tided to GCC's release
> > > > schedule.
> > >
> > > I think that is unavoidable, given that Gcc 3 has a new and
> > > incompatible C++ ABI. It is Bad if the current release of Gdb cannot
> > > debug code produced from the current release of Gcc. Therefore, Gdb
> > > 5.1 should be released before or at the same time as Gcc 3.0 is
> > > released, and it needs to have at least tolerable support for the new
> > > C++ ABI.
[snip]
> >
> > If there are important reasons why the next release of GDB should
> > support the new C++ ABI, then perhaps the GCC team should help Daniel
> > and others work on the GDB side of this support.
[snip]
> I don't agree with this.
> The GCC team is responsible for GCC, not GDB.
[Sorry for the long quotations, they are necessary in this case.]
Let me back up for a moment. See the quotations above; it goes like
this:
- Andrew says he doesn't want GDB's release schedule to be directly
tied to GCC's releases (FWIW, I'm with Andrew on this one);
- Per replies that it is very important that GDB _does_ release its
new version with the new C++ ABI support together with GCC 3.0;
- To this I say that if the GCC teams wants it so badly, they
should come on board and help.
In other words, I also don't think that the GCC team should be
developing GDB. What I am saying is that if they think our decisions
are not good enough for them, they have the opportuninty to make a
difference by contributing the code.
next prev parent reply other threads:[~2001-02-16 2:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-14 8:49 Michael Elizabeth Chastain
2001-02-15 10:27 ` Andrew Cagney
2001-02-15 13:46 ` Per Bothner
2001-02-15 15:06 ` Andrew Cagney
2001-02-15 15:14 ` Per Bothner
2001-02-15 23:35 ` Eli Zaretskii
2001-02-16 0:58 ` Daniel Berlin
2001-02-16 2:32 ` Eli Zaretskii [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-02-14 10:24 Michael Elizabeth Chastain
2001-02-14 8:52 Michael Elizabeth Chastain
2001-02-14 10:06 ` Daniel Berlin
2001-02-14 0:06 Michael Elizabeth Chastain
2001-02-14 7:31 ` Andrew Cagney
2001-02-14 8:28 ` Daniel Berlin
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=200102161032.FAA04544@indy.delorie.com \
--to=eliz@delorie.com \
--cc=ac131313@cygnus.com \
--cc=dberlin@redhat.com \
--cc=gdb@sources.redhat.com \
--cc=per@bothner.com \
/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