extending libgcc's exception delivery path

[Mike Stump]

> From: Godmar Back <gback@cs.utah.edu>
> To: mrs@windriver.com (Mike Stump)
> Date: Tue, 7 Dec 1999 18:49:54 -0700 (MST)

> Okay, I'm dense.  

No, we just aren't talking about the same thing I guess.  To me `check
whether the frame is inside some special assembly code for which I
don't have exception handling information and if so skip it' means
that there does not exist any EH information about the frame.  `so
skip it' means unwind that frame.  Unwinding a frame can only be done
in certain tightly controlled situations (all code compiled by the
same version of gcc, and/or so on).  Generally it isn't possible to
`so skip it' when `I don't have exception information.'  Anyway, we
can safely skip this subpart.

> If my assembly function had been generated by a compiler (that's
> possible, isn't it?),

This is one of those trival to get right cases that is not
representative of the harder cases.

> It seems horribly complicated to require a catch/rethrow for such
> simple "X" as restoring a callee-saving register, but I agree that
> it would cover that case.

Well, one can do it in other ways, if they want.  For example, one can
imagine the jitters getting together and setting up standard ways that
all jit systems use to gen EH stuff that will interoperate nicely.  We
then extend out the scheme in gcc to include this.  You can think of
the DWARF2 scheme that is in there now as one such optimization that
the precompiled langauges have all banded together to use.  There used
to be another in there called inline unwinders that is essentially
what I described in my last email to you.

> The current implementation takes 1 word per jitted method (to store
> the size of the local variables) and it takes ca. 16 lines of
> C code without branches to restore the registers.  I'm unlikely to 
> prefer implementing dwarf generation to this.  Keep in mind that
> the only action "X" to be undone by jitted code is to restore callee-saved
> registers, which are always eagerly saved at a known, constant offset.
> This is also not an investment anybody would hang on to should the need
> for more complicated mechanisms arise.  

Sounds quite reasonable and logical.  In fact, it sounds like one of
my prior EH schemes.  :-) Hum, instead of a dumb hook, you might want
to donate the code to libgcc.a and have it live there, and then just
use it.  We can then encourage other jitters to use the _same_
interface that you use (same problem after all).  All the effort that
others put into refining it, you then get for free, and all the work
that you put into it, they (with some luck) can reuse.

With a little clever use of weak it might be possible to not bloat the
static a.outs with the scheme, if the module isn't otherwise dragged
in.

Just some random thoughts...