Dynamically generated code and DWARF exception handling

[Mike Stump]

On May 4, 2006, at 5:05 AM, jacob navia wrote:
> Well, I searched for those and found some usage examples in the  
> source of Apple Darwin gcc code for the startup. But then... is  
> that current?

This question lacks any detail that would allow me to answer it.   
With enough detail, I could.

> ALL of this is extremely confusing and I am getting scared really.

This list is isn't for people that get really scared.

> Then, I will try to figure out from the source what they are doing  
> and what they expect. As far as I know, there is no AMD64 specific  
> docs, just ITANIUM docs that *could* be used for AMD64 but nobody  
> knows for sure

We know for sure.  The answer is yes.

> if those docs apply or they are just obsolete.

No, they are not obsolete.

One approach to solving this might be to do up your code following  
the windows api, and then ask of specific questions on how to  
implement that api.  In the end, you can contribute that api to gcc,  
and the next soul to want to do this would have an easier time.  I  
think that might make a reasonable addition (I'm assuming sanity in  
the windows api) to gcc.  If not, a simplified form of it hopefully  
would.

The problem I see is related to libffi and the fact that the one abi  
has to support every target, both now, and all future ones.  Not  
sure, but maybe expanding libffi to handle this case is the right  
direction.

Another idea, is to, for each function foo you want to call on the  
system, generate:

foo_prime() { try{ foo(); } catch (...) { longjmp() } }

with the system compiler and have the JIT dispatcher do the  
corresponding setjmp, and when it comes back into it, rethrow from  
there.  This trades a host of problems for a different set of  
problems.  In doing the library, you're need to understand the dwarf  
EH stuff, in the later scheme, no dwarf EH bits.