Re: extending libgcc's exception delivery path

[Godmar Back <gback at cs dot utah dot edu>]

> 
> I think it makes sense to extend the current unwinding API to support other
> representations; this will be necessary to support using the ia64 unwind
> descriptors, for instance.  A Java interpreter could then provide its own
> routines for unwinding.  But I think I'd prefer to hook it in at a lower
> level, associating the address range for interpreted code with the Java
> routines and having the unwinder look that up.
> 

Regarding who should look up the address range,  I would like you to
consider a few things:

- There may not be a single continuous address range.    I'm not sure
  whether you implied this in your last sentence or not.
  [ It would be too simplistic to say: 
    if (pc >= heap_start && pc < heap_end) must_be_jitted_code(); ]

- There may already be space-efficient lookup mechanisms to find a frame.
  For instance, in Kaffe, because its allocator allocates the memory
  where jitted code is stored, I can use the allocator's data structures
  to find a frame;  having all lookup going through the unwinder may
  require a certain memory cost in terms of duplicated information
  in bookkeeping information.  It is also not necessarily faster.
 
- "Flexibility".  Well, maybe flexibility isn't the right word.
  For its JNI subsystem, Kaffe uses a second, setjmp/longjmp-based
  exception handling system.  One of the tricks I'm currently playing 
  is to "assign" a "magic" longjmp handler to all JNI-related frames.
  These frames are actually plain C code.  While that may be a gross
  hack, a well-designed solution would have to allow for something
  equivalent.  What I mean specifically is taking a special action 
  when unwinding plain C frames for which there is no exception 
  handler in the object file.  Maybe an __attribute__ (catch = ...) that 
  would deliver exceptions to some handler when an exception unrolls 
  such a function?

	- Godmar