[Mono-devel-list] AMD64, PInvoke + Native Exceptions
Willibald Krenn
Willibald.Krenn at gmx.at
Sun Oct 24 18:59:37 EDT 2004
Hi!
> > 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!
Willi
--
+++ 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