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

[Zoltan Varga]

                                       Hi,

On Sun, 24 Oct 2004 21:20:24 +0200 (MEST), Willibald Krenn
<willibald.krenn at gmx.at> wrote:
> 
> Jó napot!
> 
> > > exceptions thrown in e.g. a g++ compiled .so,
> >
> > This will not be implemented in the near future.
> 
> I see. But it should be possible to catch those exceptions by implementing a
> custom personality routine for exception handling - if I'm not mistaken.
> Will look into that.
> 
> > > BTW: LMF seems pretty senseless on AMD64, or have I missed something..
> >
> > LMF is used to return to the last managed method in case the unmanaged
> > method
> > threw an exception. This is used when the internal runtime code throws
> > an .NET exception,
> > for example. It is also used when there is a segmentation fault in
> > unmanaged code.
> 
> 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.)
> 
> 
> > > Another question that arose has to do with OP_CHECK_THIS: Am I right
> > that
> > > this is not fully implemented yet?
> > >
> >
> > OP_CHECK_THIS works by loading the value pointed to by the given this
> > variable. If
> > the variable is null, a SIGSEGV is sent to the thread, which will be
> > converted to a
> > NullReferenceException by the exception handling code.
> 
> 
> Well, so how does that work in the following case:
> [... Next, the code will call the constructor of the
> System.NotImplementedException  class, thereby passing the 'this' (self)
> pointer as argument in %rdi.
>  Interestingly enough, the pointer is compared to NULL, but no conditional
>  jump can be found before the callq opcode.
>  Essentially, the cmp opcode comes from an OP_CHECK_THIS(?) mono
> intermediate instruction and should issue an exception when 'this' is found
> to be NULL. The check, however, does not seem to be completely implemented
> yet.]

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

>   35:   49 8b ff                mov    %r15,%rdi
>   38:   49 83 3f 00             cmpq   $0x0,(%r15)
>   3c:   49 bb 30 6b f0 96 2a    mov    $0x2a96f06b30,%r11
>   43:   00 00 00
>   46:   49 ff d3                callq  *%r11
> 
> By looking at the code above, it's pretty obvious that mono issues calls on
> AMD64 by a "mov IMM8, reg\n  call *reg" opcode combination. You've a fixme
> in the codegen header at this position IIRC: Does that mean you want to use
> the IP-relative imm4 version, if the call target is in reach?
> 

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.

                Zoltan

> 
> > > And the last one: When stepping through code with ddd, I often get SIG35
> > > exceptions.. Anything I can do about that?
> > >
> > Some signals are used by the runtime/libgc for suspending/aborting
> > threads etc. These
> > can be ignored during debugging by the gdb 'handle' command.
> 
> Ah, ok. Thanks!
> I already disabled PWR and another signal, but was not aware that there are
> more signals to ignore.
> 
> Willi
> 
> --
> Geschenkt: 3 Monate GMX ProMail + 3 Ausgaben der TV Movie mit DVD
> ++++ Jetzt anmelden und testen http://www.gmx.net/de/go/mail ++++
> 
>