[Mono-dev] [PATCH] Use trampolines for vtable fixups

[Kornél Pál]

The ChangeLog is in the e-mail. Final changelog will be a bit more 
detailed but I believe this is not the final patch yet.

Most of the code is not in PLATFORM_WIN32 so I would like to ask people 
to test this patch on other platforms as well.

The SEH stuff can't break gcc because it's in _MSC_VER.

Kornél

Rodrigo Kumpera wrote:
> Hi Kornel,
> 
> Your patch have a few issues. First, it does a lot of different stuff in 
> the same patch, second no Changelog entries are provided.
> 
> My suggestion is that yo split it in the following pieces and add 
> Changelog entries so they can properly reviewed:
> 
> -The change to mono_gc_init (). This affects all platforms and require 
> more reviewer effort that the rest.
> 
> -SEH for reading mapped images. Can this change break cygwin/mingw builds?
> 
> -coree/vtable fixups stuff. This one requires less reviewing as your're 
> the author of it and it doesn't affect other targets.
> 
> Thanks,
> Rodrigo
> 
> 
> 2009/5/5 Kornél Pál <kornelpal at gmail.com <mailto:kornelpal at gmail.com>>
> 
>     Hi,
> 
>     The attached patch implements using trampolines for vtable fixups
>     that delay assembly loading. I believe that this is the correct
>     solution.
> 
>     This patch also modifies:
> 
>     1) EXE image is only fixed up when using driver.c; embedded mono.dll
>     will not improperly tamper the image used for version initialization.
> 
>     2) Use SEH with MS VC++ for reading mapped image. (GCC has no
>     support for that:( )
> 
>     3) Disallow unloading mono.dll after mscoree.dll was fixed up to
>     prevent calling unmapped functions.
> 
>     4) Remove WaitForSingleObjectEx in mono_gc_init () by modifying
>     mono_thread_create_internal to return the thread object.
> 
>     This latter also affects other platform. I would like to ask you to
>     test it. I wasn't able to reproduce any deadlock related to this. (I
>     only found a deadlock with socket accept on Windows that was
>     discussed earlier on the list.) If you can reproduce a deadlock
>     related to finalizer thread I am willing to help solving that but I
>     need the exact locaions of deadlocked thread stack traces.
> 
>     Kornél
> 
>     _______________________________________________
>     Mono-devel-list mailing list
>     Mono-devel-list at lists.ximian.com
>     <mailto:Mono-devel-list at lists.ximian.com>
>     http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 
>