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

[Willibald Krenn]

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.]
  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?

 
> > 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 ++++