[Mono-devel-list] malloc and free on CLI

[Kornél Pál]

And please look at http://bugzilla.ximian.com/show_bug.cgi?id=75480

Both PureClr.exe and PureClrNoCrt.exe are compiled by MS VC++ using
/clr:pure. PureClrNoCrt.exe is supported by Mono because it is not using
CRT.

PureClr.exe could be supported by Mono on Win32 because it has all the
referenced DLLs but is not supported becuase it wants to pass managed object
from Mono to MS .NET runtime. (The function is exported by the DLL through
CLR).

----- Original Message -----
> From: Ben Maurer
> Not really. Dllmaps could map from a "virtual" libc library to the real
> libc. If you want to be especially clever and make the application run
> on the msft runtime, the library name should be whatever the ms C
> runtime is, since windows doesn't have dllmaps.

You are right this is a much easier implementations.:)

> Looking forward (in the medium-long term), the way icalls work is going
> to need to change. For a precise GC to work, we'll need to know exactly
> which calls hold gc references. icalls will probably need code to
> interact with safepoints. So, it would seem that something like that is
> prone to break.

I think something equivalent to icall has to exsist because a lot of
functionality of the Class Library has to be implemented in native code. A
managed C runtime library could be part of the Class Library and thus it
could use this functionality.

I was viewing the situation from the point of view of the application not
the runtime.:) Ideally Mono should be able to execute /clr:pure managed C++
applications (guaranted to be IL only). The only problem is that MS VC++
compiler uses P/Invoke instead of metadata references. It has a C runtime
DLL said to be managed but is is mixed native and managed code in fact. The
worse thing is that MS VC++ compiler produces code that references
kernel32.dll using P/Invoke and passes managed objects to managed C runtime
DLL using P/Invoke. Furtermore the runtime DLL exports managed functions
using PE export table. This makes this whole solution very platform and
runtime dependent.

Note that /clr:safe is supported by Mono runtime but it cannot take
advantage of C runtime because it uses pointers in function parameters that
makes it unverifiable and it could be use only by explicit P/Invoke function
declarations.

Passing managed object using P/Invoke is not supported by Mono runtime.

So some kind of special C runtime handling code will be necessary in the
runtime to map P/Invoke calls to managed or internal native functions to can
pass managed objects to P/Invoke funtions. And kernel32.dll calls in the
managed assembly should be handled by the runtime as well.

As a conclusion if we will be able to support assemblies compiled by MS VC++
it will require a lot of tricky code because it cannot be done just by
creating a native C runtime that is called using P/Invoke. So I think it
doesn't matter whether we use managed or native C runtime as we will have to
do function mapping anyway.

Having a fulliy managed libc has a lot of advantages but a native libc has
advantages as well. I personally prefer a managed libc because the assembly
using libc is managed code itself.

> Also, using icalls means that you must link with libmono.so, preventing
> an application from running on the msft runtime.

A GCC/CIL compiler will produce IL code so it will be executed against the
CLR and will not be linked to any native libraries. The library itsef should
be part of the Class Library. If we will not able to use an MS compatible C
runtime library then the resulting runtime library could use icalls on Mono
and use P/Invoke to heap functions of Win32.

Kornél