Re: C++ FAIL counts and the effect of demangler fix

[Daniel Berlin <dberlin at redhat dot com>]

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.
> > 
> > Otherwise, we may have to live with the situation (and I don't
> > actually know what the situation is), but make no mistake: This is
> > a critical issue for many people, Red Hat included.  (OS distributors
> > may have a hard time switching to Gcc 3.0 if there are critical Gdb
> > regressions.)
> 
> 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. 

While i'd be happy for the support, ....
>  Or maybe you should
> consider delaying the release of GCC 3.0 in the same manner as you are
> suggesting that GDB will delay its release.
> 
> This is not an issue with GDB alone.  The change of the ABI was in
> GCC, so I think the GCC team should share the responsibility for
> making GDB support it.

I don't agree with this.
The GCC team is responsible for GCC, not GDB.
Why should they have to be coding support for things in GDB?

Sure, we should be connected, and informed of what the GCC team is
doing, and they, informed of what we are doing, in timely fashion such
that we can make the two work well together, but saying they have a
responsibility to actually implement gdb functionality is, IMHO, going
to far.

Fer instance, if they change GCC to emit dwarf2 location expressions
in something they plan to release in ~8 months (estimated of course, but
guaranteed to not be *shorter* than 8 months), and tell us, why the
heck should they have to implement dwarf2 location expression support
in GDB?  That's a big job, and not easy for someone not familiar with
th dwarf2 *reader*, or the symbol table structures, etc, by a long
shot. It would be *better* done by someone on the gdb team.

Saying they have share any kind of responsibility for us supporting it
just feels wrong to me. I'm okay with saying they have a
responsibility to make sure we know about the stuff, but not that they
have any responsibility to actually implement it.

Regardless, besides virtual functions, i've got the rest abstracted so
that it works for both ABI's, and will be submitting it soon. And
virtual functions don't work because i'm having 
trouble following all the cases in the abi, and generating the code
necessary to perform the same lookups. The rest of the issues are
mainly cosmetic, and don't take more than a day or two to fix (IMHO).

I also haven't readded HP's C++ ABI stuff, since it was *so*
improperly inlined, pieces need to rewritten (I've verified that they
*can* be implemented in terms of the new C++ abi abstraction stuff, i
just have no way of doing so and testing the result. Though I will
attempt it if requested).

The only real need for any delay will depend on how long it takes to
get the patches to be reviewed. They aren't particularly large, but
touch a whole bunch of code to get rid of stuff, like macros that were too
specific to one abi that each abi had (named different things of
course), and were replaced with a canonical function that all the
abi's implement instead. 
--Dan