On Wed, 2009-11-04 at 16:31 -0200, Rodrigo Kumpera wrote:
> The icall removal patch is ok.
committed
> The second one is tricky. Do we really want to completely disable COM
> support when running under the sandbox?
I don't see this as an immediate issue but...
> It does make sense for moonlight, but not for other users of coreclr.
>
> I believe we should only fail COM for non-platform assemblies which
> has the same result for moonlight
a new patch is attached.
> but won't
> bite future users of the sandbox code.
Well it won't change anything for Moonlight[1] but it will still bite
any other (well future) user of coreclr unless the BCL they provide
offers the required COM types [2]. Otherwise it will simply abort (like
id does today).
Sebastien
[1] unless someone adds a [ComImport] somewhere in the platform code -
but that would not pass our test suite :)
[2] A added a FIXME in the patch about this. In any case the g_abort
should make it clear enough to runtime embedders
>
>
> On Thu, Oct 29, 2009 at 4:43 PM, Sebastien Pouliot
> <sebast...@ximian.com> wrote:
> Hello,
>
> Two small/easy patches for review.
>
> The first one avoid calling mono_com_init when coreclr is
> enabled*.
> This avoid a crash if some assembly use [ComImport] on a type
> and throw
> a TypeLoadException - which is what happens in Silverlight.
>
> * For some reason (I guess it use COM for it's platform
> code,
> while Moonlight does not) Silverlight expose
> [ComImport] but
> otherwise does not support COM (as least for
> application code).
>
> Second patch removes some internal calls (all strings except
> one) that
> are not used (anymore) in the class libraries.
>
> Sebastien
>
> p.s. both patches were created from 2-6 branch but I'll commit
> them
> against HEAD too.
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
Index: mono/metadata/ChangeLog
===================================================================
--- mono/metadata/ChangeLog (revision 145149)
+++ mono/metadata/ChangeLog (working copy)
@@ -1,3 +1,11 @@
+2009-11-05 Sebastien Pouliot <sebast...@ximian.com>
+
+ * class.c: When CoreCLR is enabled don't call mono_init_com_types
+ if MONO_CLASS_IS_IMPORT return true unless the type reside in
+ platform (trusted) code. Instead we return a TypeLoadException to
+ be thrown later. This is the exception thrown by Silverlight 2 if
+ a type, inside application (user) code is marked with [ComImport]
+
2009-10-31 Zoltan Varga <var...@gmail.com>
* appdomain.c (mono_domain_try_unload): Applied patch from Romain Tartière.
Index: mono/metadata/class.c
===================================================================
--- mono/metadata/class.c (revision 145487)
+++ mono/metadata/class.c (working copy)
@@ -4274,6 +4274,30 @@
}
/*
+ * COM initialization (using mono_init_com_types) is delayed until needed.
+ * However when a [ComImport] attribute is present on a type it will trigger
+ * the initialization. This is not a problem unless the BCL being executed
+ * lacks the types that COM depends on (e.g. Variant on Silverlight).
+ */
+static void
+init_com_from_comimport (MonoClass *class)
+{
+ /* we don't always allow COM initialization under the CoreCLR (e.g. Moonlight does not require it) */
+ if ((mono_security_get_mode () == MONO_SECURITY_MODE_CORE_CLR)) {
+ /* but some other CoreCLR user could requires it for their platform (i.e. trusted) code */
+ if (!mono_security_core_clr_determine_platform_image (class->image)) {
+ /* but it can not be made available for application (i.e. user code) since all COM calls
+ * are considered native calls. In this case we fail with a TypeLoadException (just like
+ * Silverlight 2 does */
+ mono_class_set_failure (class, MONO_EXCEPTION_TYPE_LOAD, NULL);
+ return;
+ }
+ }
+ /* FIXME : we should add an extra checks to ensure COM can be initialized properly before continuing */
+ mono_init_com_types ();
+}
+
+/*
* LOCKING: this assumes the loader lock is held
*/
void
@@ -4299,7 +4323,7 @@
if (!MONO_CLASS_IS_INTERFACE (class)) {
/* Imported COM Objects always derive from __ComObject. */
if (MONO_CLASS_IS_IMPORT (class)) {
- mono_init_com_types ();
+ init_com_from_comimport (class);
if (parent == mono_defaults.object_class)
parent = mono_defaults.com_object_class;
}
@@ -4350,7 +4374,7 @@
} else {
/* initialize com types if COM interfaces are present */
if (MONO_CLASS_IS_IMPORT (class))
- mono_init_com_types ();
+ init_com_from_comimport (class);
class->parent = NULL;
}
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
