Re: New ABI EH (was Re: C++ PATCH: Switch to the new ABI)

[Jason Merrill <jason at redhat dot com>]

>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:

>>>>> "Jason" == Jason Merrill <jason@redhat.com> writes:
>>> This was the last remaining major bit of functionality for GCC
>>> 3.0; from now on, we will be focusing on compile-time
>>> performance, run-time performance and robustness.

Jason> Remember that the new EH ABI has still not been
Jason> implemented, so we aren't yet compliant with the ia64 ABI;

> True -- but again IA64 isn't one of our primary platforms.  I think we
> consciously decided to wait on IA64 until our next release due to the
> general newness of the platform.

True enough; the backend is still under active development.

Jason> we ought to do at least enough to provide
Jason> forward-compatibility with the new ABI before gcc 3.0.
Jason> This basically means the personality routine, unwinder API
Jason> and exception model.  We will eventually want to switch
Jason> over to the more efficient landing pad scheme, but that can
Jason> wait.

> I'm confused.  I tried to raise the issue of using the C++ bits of the
> EH model with you and RTH a while back, and I thought that y'all
> suggested that there was no reason to use a scheme other than our
> current scheme on non-IA64 targets?

> Could you clarify a little what your thinking is on this at this
> point?  For example, what do you want to do on IA32 w.r.t. EH?

RTH may have expressed that opinon, I don't remember; in any case, I
don't agree.

It seems to me that the ia64 ABI design offers a good framework for
interoperation of runtimes from different sources; our current scheme
provides a limited callback mechanism for dealing with language
semantics, but the personality routine provides more flexibility.  For
non-ia64 targets, we probably also want to provide callbacks for
alternate unwind info formats, so that a Java interpreter (say)
doesn't have to build up dwarf2 on the fly.

Apart from that, our current scheme has a fair amount of design
lossage; the fixup problem is significant and pervasive, and we call
back into the unwinder far more than necessary, which contributes to
code bloat.

And in general, it seems unproductive to maintain two different EH
APIs in the same compiler.  Presumably we want to be compatible with
the ia64 ABI on ia64, so we might as well use as much of that as is
reasonable on other targets.  IMO, the only thing we need to handle
differently is unwind info.

So there are lots of reasons to use a scheme other than our current
one; the only question is what needs to happen for 3.0.  The short
answer seems to be none; I think that we will be able to provide
backward compatibility with all aspects of the current scheme with
clever enough wrappers.  But if we don't change it now, the code will
be with us for a long time if we want to stay binary compatible.

Jason> We may be able to get a lot of this code from HP and/or
Jason> SGI.

> Perhaps.  I take it that Red Hat is not planning on contributing any
> IA64 EH C++ stuff?  (I thought that you guys might be doing this as
> part of your IA64 work; if you're not, then it would be helpful to
> know that.)

Our ia64 contract requires that we provide functional exception
handling, which we have done (see config/ia64/frame-ia64.c); it does
not require that it conform to the C++ ABI.  I've intended for us to
do the necessary work anyway, but it keeps getting deferred.

Jason