extending libgcc's exception delivery path

[Mike Stump]

> From: Godmar Back <gback@cs.utah.edu>
> Date: Mon, 6 Dec 1999 17:19:31 -0700 (MST)

> When I started the integration work, I found one or two sources with
> information about DWARF2 on the web [...] Does anybody have more
> pointers?

There is a reference from http://egcs.cygnus.com/readings.html to
ftp://sgigate.sgi.com/pub/dwarf/ on our web site.  Not sure how
complete that is for you.  I've never read it myself.

> In general, should a jit writer have to learn dwarf2 in all its glory(?)

> I believe there are other concerns too.  For instance, are libraries to 
> emit dwarf2 information available?

See the above reference, it seems this is one thing claimed of it,
though, I don't know how suitible it is for the purpose at hand, and I
don't know much about it.

> - check whether a monitor associated with that frame must be unlocked
>   and if so do it.   I don't actually know how I would do that with dwarf.

I generally do this type of work using the native EH constructs in the
source language (or specifically, the midlevel end that the frontend
uses to generate code).  Why go any lower, I don't see any advantage?

>   Is it possible, i.e., can it be expressed?

Yes.

> - check whether the frame is inside some special assembly code for which
>   I don't have exception handling information and if so skip it.

:-) Oh, the simplicity of that statement.  Sorry, this generally is
really hard to do.

> The DWARF2 information, from what I can tell, is interpreted for every
> exception thrown,  currently twice per stackframe.  Bypassing DWARF does 
> avoid repeatedly interpreting the same information over and over.

After you benchmark it, and after you devise a way to make it faster,
and after you get the maintainers to accept it...  we can talk.  I
have done multiple high performance EH implementations for gcc before,
think 218 from throw to catch block, total.  I fall over laughing at
implementations that featured 30000+ instructions.  Our current
incantation is fairly high, but it does have one feature, it is
accepted by the maintainers and is in the compiler.


New radical thought, screw dwarf.  Just use the native EH table and
put in registrations for all frame unwinding you need to do.  The
format?  Oh, too trivial to even explain:

; code outside try block
.LEHB3:
code inside try clock
.LEHE3:
code outside try block

.L3:
; handler for exceptions thrown in the try block above


__EXCEPTION_TABLE__:
; ...
.LRTH3:
        .long .LEHB3
        .long .LEHE3
        .long .L3
        .long 0


You can then `generate' code as you see fit, based upon whatever
philosophy you want to use.  It really doesn't get any simpler or
basic than this.  If you want a generic handler for frames, you just
put that handler in instead of the L3.  All of this is trival to
generate during run time, and I don't think that hard to figure out,
maintain, implement, and get working.  You then don't need any hooks
into the throw stuff, as you get control via this interface.  Also,
this interface should not change that much (though the 4 longs per
entry is new to me, it had always only been three before).

Does this work for you?