[Mono-devel-list] AMD64, PInvoke + Native Exceptions

Willibald Krenn Willibald.Krenn at gmx.at
Sun Oct 24 18:59:37 EDT 2004


> > Just to see, if I understand that correctly: In case I can come up with
> a
> > custom personality routine, LMF should not be needed on AMD64 because
> >  -> c runtime will search the DWARF info for a catch handler
> >  -> it will find the custom personality routine from the stub that
> > encapsulated the call to the internal runtime code / native code.
> >  -> the personality routine will do mono style exception handling..
> >     (As mono uses plain stack-frames and has all the meta information at
> > hands the exception handling should be doable by the personality
> routine..)
> > 
> > BTW: Throwing a C++ exception in native code just aborts mono because
> the C
> > runtime can not find any valid catch handler. So how should Mono be ever
> > able to use the LMF in case of an exception thrown in native code? (I
> guess,
> > I'm missing something here: Signals are another story for sure.)

Any comment on that assumtion? *please* :-)

> The SIGSEGV will be sent by the processor itself when %r15 is 0, and the
> runtime will convert this to a NullReferenceException.

(%r15) was the thing I overlooked - shame on me. *hiding*

> This could be optimized but this is not done yet. Mostly because
> originally
> methods make calls to trampolines which call back into the JIT to compile
> the
> method, then the call site is patched to call the newly compiled method.
> If the
> trampoline can be called with a 32 bit offset, but the newly compiled
> method
> can't, then the call site can't be patched which could lead to perf
> problems.

I understand. So trampolines and target JIT-Code area should be in a 2^31-1
bit address area for this model to work without hitch.
Any idea if this would be worth implementing?

Thanks for your support!

+++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++
Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl

More information about the Mono-devel-list mailing list