Re: [Mono-dev] AOT and generics
Ok, just did a bug report:
https://bugzilla.xamarin.com/show_bug.cgi?id=6040
Also, I attempted to fix it, seems working so far.
I published it on github (link is inside the bug report).
On Sat, Jul 7, 2012 at 12:21 AM, Virgile Bello virgile.be...@gmail.comwrote:
Thanks for the confirmation, that's what I could guess as well (one shared
code for every ref instance).
However, in that case, I can't think of any way this code can run because
for every ref type in A, the method B::TestXT() will need to be
generated (X being a struct -- it's just like bringing a non-shareable
struct type into the shared generic instance). Basically, if the class is
requested with T, if it has any method call depending on T, they should be
generated. It seems to actually be done if B::TestT is called but not
B::TestXT. There might be some other related cases as well (when
bringing a struct into a generic type). That's why I was suggesting sharing
might be problematic in this case, I will take a look at the code to have a
better idea of it.
Also, I will double check my setup, but it pretty seems standard (other
AOT stuff works fine, experimenting under linux x64).
Anyway, I will fill a bug to not pollute the mailing list too much.
Virgile
On Fri, Jul 6, 2012 at 11:39 PM, Rodrigo Kumpera kump...@gmail.comwrote:
The FullAOT compiler handles generics by compiling a single shared
instance for all ref-only type arguments.
so Listobject shares code with Liststring but Listint gets its own
version. This is the default behavior.
If this is not the case, then you have something broken in your setup.
On Fri, Jul 6, 2012 at 11:24 AM, Virgile Bello
virgile.be...@gmail.comwrote:
It would be for platforms supporting only AOT.
Of course we would license Mono. We already had a quick discussion about
licensing maybe a year ago (it's still RD/proof of concept for now, and it
was only Windows until now so we just delayed actual deal until necessary),
but thanks for pointing out, maybe now is a good time to start the
discussion again with Xamarin, I will send an email right away.
On Fri, Jul 6, 2012 at 10:31 PM, Rodrigo Kumpera kump...@gmail.comwrote:
You need to correctly drive the FullAOT compiler.
Why do you want to use FullAOT anyway?
Do you plan to run it on a target that disables JIT?
Do you hold a license that allows you to do so? Mono is LGPL and
FullAOT doesn't work with it.
On Fri, Jul 6, 2012 at 9:29 AM, Virgile Bello
virgile.be...@gmail.comwrote:
During full AOT, It seems that if generics is a ref type, AOT is
skipped (which makes sense because most of the time it is not necessary,
one codegen for any ref type is usually enough).
However, if the class internally uses a struct based on the generic
types, it will fail at runtime.
Here is a simple example showcasing the issue:
public class B
{
public void TestT()
{
System.Console.WriteLine(typeof(T));
}
}
public class AT
{
public void Test()
{
new B().TestSystem.Collections.Generic.KeyValuePairT, T();
}
}
class P
{
static void Main(string[] args)
{
new Aint().Test();
new Astring().Test();
}
}
If I run this program with full aot, it will fail.
new Aint will work (AOT forced because value type)
However, new Astring will generate a JIT exception (because even
though string is a ref type, A should be AOT for this specific type
because
KeyValuePair inside AT needs to be JITed.)
But maybe I misunderstood the problem (or it is just a specific bug),
because this other case actually work (I was expecting it to have the same
issue):
public class B
{
public void TestT()
{
System.Console.WriteLine(typeof(System.Collections.Generic.KeyValuePairT,
T));
}
}
public class AT
{
public void Test()
{
new B().TestT();
}
}
class P
{
static void Main(string[] args)
{
new Aint().Test();
new Astring().Test();
}
}
Just wanted to check if I understood the issue right and if there
would be nothing preventing from fixing it?
I wouldn't mind taking a look at the sources by myself if necessary.
Virgile
___
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
[Mono-dev] AOT and generics
During full AOT, It seems that if generics is a ref type, AOT is skipped
(which makes sense because most of the time it is not necessary, one
codegen for any ref type is usually enough).
However, if the class internally uses a struct based on the generic types,
it will fail at runtime.
Here is a simple example showcasing the issue:
public class B
{
public void TestT()
{
System.Console.WriteLine(typeof(T));
}
}
public class AT
{
public void Test()
{
new B().TestSystem.Collections.Generic.KeyValuePairT, T();
}
}
class P
{
static void Main(string[] args)
{
new Aint().Test();
new Astring().Test();
}
}
If I run this program with full aot, it will fail.
new Aint will work (AOT forced because value type)
However, new Astring will generate a JIT exception (because even though
string is a ref type, A should be AOT for this specific type because
KeyValuePair inside AT needs to be JITed.)
But maybe I misunderstood the problem (or it is just a specific bug),
because this other case actually work (I was expecting it to have the same
issue):
public class B
{
public void TestT()
{
System.Console.WriteLine(typeof(System.Collections.Generic.KeyValuePairT,
T));
}
}
public class AT
{
public void Test()
{
new B().TestT();
}
}
class P
{
static void Main(string[] args)
{
new Aint().Test();
new Astring().Test();
}
}
Just wanted to check if I understood the issue right and if there would be
nothing preventing from fixing it?
I wouldn't mind taking a look at the sources by myself if necessary.
Virgile
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] AOT and generics
It would be for platforms supporting only AOT.
Of course we would license Mono. We already had a quick discussion about
licensing maybe a year ago (it's still RD/proof of concept for now, and it
was only Windows until now so we just delayed actual deal until necessary),
but thanks for pointing out, maybe now is a good time to start the
discussion again with Xamarin, I will send an email right away.
On Fri, Jul 6, 2012 at 10:31 PM, Rodrigo Kumpera kump...@gmail.com wrote:
You need to correctly drive the FullAOT compiler.
Why do you want to use FullAOT anyway?
Do you plan to run it on a target that disables JIT?
Do you hold a license that allows you to do so? Mono is LGPL and FullAOT
doesn't work with it.
On Fri, Jul 6, 2012 at 9:29 AM, Virgile Bello virgile.be...@gmail.comwrote:
During full AOT, It seems that if generics is a ref type, AOT is skipped
(which makes sense because most of the time it is not necessary, one
codegen for any ref type is usually enough).
However, if the class internally uses a struct based on the generic
types, it will fail at runtime.
Here is a simple example showcasing the issue:
public class B
{
public void TestT()
{
System.Console.WriteLine(typeof(T));
}
}
public class AT
{
public void Test()
{
new B().TestSystem.Collections.Generic.KeyValuePairT, T();
}
}
class P
{
static void Main(string[] args)
{
new Aint().Test();
new Astring().Test();
}
}
If I run this program with full aot, it will fail.
new Aint will work (AOT forced because value type)
However, new Astring will generate a JIT exception (because even though
string is a ref type, A should be AOT for this specific type because
KeyValuePair inside AT needs to be JITed.)
But maybe I misunderstood the problem (or it is just a specific bug),
because this other case actually work (I was expecting it to have the same
issue):
public class B
{
public void TestT()
{
System.Console.WriteLine(typeof(System.Collections.Generic.KeyValuePairT,
T));
}
}
public class AT
{
public void Test()
{
new B().TestT();
}
}
class P
{
static void Main(string[] args)
{
new Aint().Test();
new Astring().Test();
}
}
Just wanted to check if I understood the issue right and if there would
be nothing preventing from fixing it?
I wouldn't mind taking a look at the sources by myself if necessary.
Virgile
___
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
Re: [Mono-dev] AOT and generics
Thanks for the confirmation, that's what I could guess as well (one shared
code for every ref instance).
However, in that case, I can't think of any way this code can run because
for every ref type in A, the method B::TestXT() will need to be
generated (X being a struct -- it's just like bringing a non-shareable
struct type into the shared generic instance). Basically, if the class is
requested with T, if it has any method call depending on T, they should be
generated. It seems to actually be done if B::TestT is called but not
B::TestXT. There might be some other related cases as well (when
bringing a struct into a generic type). That's why I was suggesting sharing
might be problematic in this case, I will take a look at the code to have a
better idea of it.
Also, I will double check my setup, but it pretty seems standard (other AOT
stuff works fine, experimenting under linux x64).
Anyway, I will fill a bug to not pollute the mailing list too much.
Virgile
On Fri, Jul 6, 2012 at 11:39 PM, Rodrigo Kumpera kump...@gmail.com wrote:
The FullAOT compiler handles generics by compiling a single shared
instance for all ref-only type arguments.
so Listobject shares code with Liststring but Listint gets its own
version. This is the default behavior.
If this is not the case, then you have something broken in your setup.
On Fri, Jul 6, 2012 at 11:24 AM, Virgile Bello virgile.be...@gmail.comwrote:
It would be for platforms supporting only AOT.
Of course we would license Mono. We already had a quick discussion about
licensing maybe a year ago (it's still RD/proof of concept for now, and it
was only Windows until now so we just delayed actual deal until necessary),
but thanks for pointing out, maybe now is a good time to start the
discussion again with Xamarin, I will send an email right away.
On Fri, Jul 6, 2012 at 10:31 PM, Rodrigo Kumpera kump...@gmail.comwrote:
You need to correctly drive the FullAOT compiler.
Why do you want to use FullAOT anyway?
Do you plan to run it on a target that disables JIT?
Do you hold a license that allows you to do so? Mono is LGPL and FullAOT
doesn't work with it.
On Fri, Jul 6, 2012 at 9:29 AM, Virgile Bello
virgile.be...@gmail.comwrote:
During full AOT, It seems that if generics is a ref type, AOT is
skipped (which makes sense because most of the time it is not necessary,
one codegen for any ref type is usually enough).
However, if the class internally uses a struct based on the generic
types, it will fail at runtime.
Here is a simple example showcasing the issue:
public class B
{
public void TestT()
{
System.Console.WriteLine(typeof(T));
}
}
public class AT
{
public void Test()
{
new B().TestSystem.Collections.Generic.KeyValuePairT, T();
}
}
class P
{
static void Main(string[] args)
{
new Aint().Test();
new Astring().Test();
}
}
If I run this program with full aot, it will fail.
new Aint will work (AOT forced because value type)
However, new Astring will generate a JIT exception (because even
though string is a ref type, A should be AOT for this specific type because
KeyValuePair inside AT needs to be JITed.)
But maybe I misunderstood the problem (or it is just a specific bug),
because this other case actually work (I was expecting it to have the same
issue):
public class B
{
public void TestT()
{
System.Console.WriteLine(typeof(System.Collections.Generic.KeyValuePairT,
T));
}
}
public class AT
{
public void Test()
{
new B().TestT();
}
}
class P
{
static void Main(string[] args)
{
new Aint().Test();
new Astring().Test();
}
}
Just wanted to check if I understood the issue right and if there would
be nothing preventing from fixing it?
I wouldn't mind taking a look at the sources by myself if necessary.
Virgile
___
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
Re: [Mono-dev] Mono Soft Debugger
I wrote a small (50 lines of code) monodevelop addin bound to F3 so that I don't need to setup any solution, just run the exe. Please let me know if you are interested in sources. On 2011/02/26, at 14:45, Miguel de Icaza mig...@novell.com wrote: I just have a single, minor issue that I don't seem capable of solving: When I open an application using the Debug/Debug Application menu item, it opens the application, runs it immediately and therefore does not allow me to set breakpoints and single-step the program. I have tried opening a source file beforehand and setting a breakpoint, but that doesn't seem to work either. Is there a chance that MonoDevelop could be altered so that it set up a breakpoint on Main the very moment that the application is loaded? That way, one could debug using MonoDevelop and I could perhaps spend some time helping out on MonoDevelop instead of wasting a lot of time on reinventing the wheel. This probably needs to be better documented. Use File/Open and navigate to your executable. Open the executable, this will create a solution and it will automatically show you the source files that the executable depends on (as long as you compiled with -debug). Set breakpoints, and start your program. Miguel ___ 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
[Mono-dev] Soft Debugger issues (can't suspend threads in wait_for_suspend)
I am having trouble with mono soft debugger. - I embed Mono runtime in my program, and I got MonoDevelop to act as SoftDebugger client - Mono soft debugger is loading properly (first breakpoint usually works -- if already set beforehand -- I can see callstacks, etc...) - As soon as I press F5 -- to execute until this breakpoint is reached again next iteration -- or if I disable/reenable this breakpoint, program hang (see log) - Main loop is in C and Mono functions are called regularly. I traced down the problem to thread(s) not suspending (cf log). Usually, it seems it is the Finalizer thread (in this case 2054) that doesn't get suspended. In mono sources, I tried to call mono_gc_collect/mono_gc_invoke_finalizers in the suspend_thread loop. In that case, I can manage to have F5 working (breakpoint trigger every step inside the loop). However it doesn't work as soon as I do anything else (such as removing adding again the breakpoint). I remember seeing this problem on more than 1 thread when I had other threads active (i.e. Waiting for 3(4) threads to suspend...) Does anyone have an idea? Maybe there is something special to do if Mono doesn't keep hand (often back to full unmanaged world since main loop is in C) Debugger log: [0410] Thread started, obj=04702F20, tls=004CDA60. [0410] Suspended. [0410] Resumed. [0410] Suspending vm... [0410] Sent event VM_START, suspend=2. [0410] Suspended. [dbg] Agent thread started, pid=1260 [2054] Thread started, obj=04702E70, tls=004EC1D8. Finalizer thread [2054] Suspended. [dbg] Received command VM(VERSION), id=1. [dbg] Received command VM(SET_PROTOCOL_VERSION), id=2. [dbg] Protocol version 2.2, client protocol version 2.2. [dbg] Received command APPDOMAIN(1), id=3. ... [0410] Suspended. [dbg] Received command TYPE(1), id=1785. [dbg] Received command TYPE(6), id=1786. [2054] Received single step event for suspending. [2054] Suspended. [dbg] Received command VM(RESUME), id=1787. [1260] Resuming vm... [2054] Resumed. [0410] Resumed. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event TYPE_LOAD, suspend=2. [0410] Suspended. [dbg] Received command TYPE(1), id=1788. [dbg] Received command TYPE(6), id=1789. [2054] Received single step event for suspending. [2054] Suspended. [dbg] Received command VM(RESUME), id=1790. [1260] Resuming vm... [2054] Resumed. [0410] Resumed. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event TYPE_LOAD, suspend=2. [0410] Suspended. [dbg] Received command TYPE(1), id=1791. [dbg] Received command TYPE(6), id=1792. [dbg] Received command VM(RESUME), id=1793. [2054] Received single step event for suspending. [2054] Suspended. [1260] Resuming vm... [0410] Resumed. [2054] Resumed. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event TYPE_LOAD, suspend=2. [0410] Suspended. [dbg] Received command TYPE(1), id=1794. [dbg] Received command TYPE(6), id=1795. [dbg] Received command VM(RESUME), id=1796. [1260] Resuming vm... [0410] Resumed. [0410] Breakpoint hit, method=Step, offset=0x1e. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event BREAKPOINT, suspend=2. [0410] Suspended. [dbg] Received command VM(ALL_THREADS), id=1797. [dbg] Received command THREAD(1), id=1798. Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Soft Debugger issues (can't suspend threads in wait_for_suspend)
Just as a small addition, to confirm what I said earlier concerning situation with additional threads. After adding 2 threads that don't actually call mono (simply register them with mono_thread_attach(mono_get_root_domain())), I end up having: Waiting for 2(4) threads to suspend... which mean 1 of the fully native threads is also blocking it. Maybe it can't detect well when threads are running in native mode? I will continue to investigate as well. On Wed, Jan 26, 2011 at 12:58 AM, Virgile Bello virgile.be...@gmail.comwrote: I am having trouble with mono soft debugger. - I embed Mono runtime in my program, and I got MonoDevelop to act as SoftDebugger client - Mono soft debugger is loading properly (first breakpoint usually works -- if already set beforehand -- I can see callstacks, etc...) - As soon as I press F5 -- to execute until this breakpoint is reached again next iteration -- or if I disable/reenable this breakpoint, program hang (see log) - Main loop is in C and Mono functions are called regularly. I traced down the problem to thread(s) not suspending (cf log). Usually, it seems it is the Finalizer thread (in this case 2054) that doesn't get suspended. In mono sources, I tried to call mono_gc_collect/mono_gc_invoke_finalizers in the suspend_thread loop. In that case, I can manage to have F5 working (breakpoint trigger every step inside the loop). However it doesn't work as soon as I do anything else (such as removing adding again the breakpoint). I remember seeing this problem on more than 1 thread when I had other threads active (i.e. Waiting for 3(4) threads to suspend...) Does anyone have an idea? Maybe there is something special to do if Mono doesn't keep hand (often back to full unmanaged world since main loop is in C) Debugger log: [0410] Thread started, obj=04702F20, tls=004CDA60. [0410] Suspended. [0410] Resumed. [0410] Suspending vm... [0410] Sent event VM_START, suspend=2. [0410] Suspended. [dbg] Agent thread started, pid=1260 [2054] Thread started, obj=04702E70, tls=004EC1D8. Finalizer thread [2054] Suspended. [dbg] Received command VM(VERSION), id=1. [dbg] Received command VM(SET_PROTOCOL_VERSION), id=2. [dbg] Protocol version 2.2, client protocol version 2.2. [dbg] Received command APPDOMAIN(1), id=3. ... [0410] Suspended. [dbg] Received command TYPE(1), id=1785. [dbg] Received command TYPE(6), id=1786. [2054] Received single step event for suspending. [2054] Suspended. [dbg] Received command VM(RESUME), id=1787. [1260] Resuming vm... [2054] Resumed. [0410] Resumed. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event TYPE_LOAD, suspend=2. [0410] Suspended. [dbg] Received command TYPE(1), id=1788. [dbg] Received command TYPE(6), id=1789. [2054] Received single step event for suspending. [2054] Suspended. [dbg] Received command VM(RESUME), id=1790. [1260] Resuming vm... [2054] Resumed. [0410] Resumed. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event TYPE_LOAD, suspend=2. [0410] Suspended. [dbg] Received command TYPE(1), id=1791. [dbg] Received command TYPE(6), id=1792. [dbg] Received command VM(RESUME), id=1793. [2054] Received single step event for suspending. [2054] Suspended. [1260] Resuming vm... [0410] Resumed. [2054] Resumed. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event TYPE_LOAD, suspend=2. [0410] Suspended. [dbg] Received command TYPE(1), id=1794. [dbg] Received command TYPE(6), id=1795. [dbg] Received command VM(RESUME), id=1796. [1260] Resuming vm... [0410] Resumed. [0410] Breakpoint hit, method=Step, offset=0x1e. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event BREAKPOINT, suspend=2. [0410] Suspended. [dbg] Received command VM(ALL_THREADS), id=1797. [dbg] Received command THREAD(1), id=1798. Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Soft Debugger issues (can't suspend threads in wait_for_suspend)
Sorry, last small update, if I simply disable the waiting loop in wait_for_suspend() and make is_suspended() always return TRUE, breakpoints/tracing work as expected (except maybe playing with other threads of course). This seems to confirm there might be some false positive when trying to detect threads that run in native mode (mono think they are managed). On Wed, Jan 26, 2011 at 1:06 AM, Virgile Bello virgile.be...@gmail.comwrote: Just as a small addition, to confirm what I said earlier concerning situation with additional threads. After adding 2 threads that don't actually call mono (simply register them with mono_thread_attach(mono_get_root_domain())), I end up having: Waiting for 2(4) threads to suspend... which mean 1 of the fully native threads is also blocking it. Maybe it can't detect well when threads are running in native mode? I will continue to investigate as well. On Wed, Jan 26, 2011 at 12:58 AM, Virgile Bello virgile.be...@gmail.comwrote: I am having trouble with mono soft debugger. - I embed Mono runtime in my program, and I got MonoDevelop to act as SoftDebugger client - Mono soft debugger is loading properly (first breakpoint usually works -- if already set beforehand -- I can see callstacks, etc...) - As soon as I press F5 -- to execute until this breakpoint is reached again next iteration -- or if I disable/reenable this breakpoint, program hang (see log) - Main loop is in C and Mono functions are called regularly. I traced down the problem to thread(s) not suspending (cf log). Usually, it seems it is the Finalizer thread (in this case 2054) that doesn't get suspended. In mono sources, I tried to call mono_gc_collect/mono_gc_invoke_finalizers in the suspend_thread loop. In that case, I can manage to have F5 working (breakpoint trigger every step inside the loop). However it doesn't work as soon as I do anything else (such as removing adding again the breakpoint). I remember seeing this problem on more than 1 thread when I had other threads active (i.e. Waiting for 3(4) threads to suspend...) Does anyone have an idea? Maybe there is something special to do if Mono doesn't keep hand (often back to full unmanaged world since main loop is in C) Debugger log: [0410] Thread started, obj=04702F20, tls=004CDA60. [0410] Suspended. [0410] Resumed. [0410] Suspending vm... [0410] Sent event VM_START, suspend=2. [0410] Suspended. [dbg] Agent thread started, pid=1260 [2054] Thread started, obj=04702E70, tls=004EC1D8. Finalizer thread [2054] Suspended. [dbg] Received command VM(VERSION), id=1. [dbg] Received command VM(SET_PROTOCOL_VERSION), id=2. [dbg] Protocol version 2.2, client protocol version 2.2. [dbg] Received command APPDOMAIN(1), id=3. ... [0410] Suspended. [dbg] Received command TYPE(1), id=1785. [dbg] Received command TYPE(6), id=1786. [2054] Received single step event for suspending. [2054] Suspended. [dbg] Received command VM(RESUME), id=1787. [1260] Resuming vm... [2054] Resumed. [0410] Resumed. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event TYPE_LOAD, suspend=2. [0410] Suspended. [dbg] Received command TYPE(1), id=1788. [dbg] Received command TYPE(6), id=1789. [2054] Received single step event for suspending. [2054] Suspended. [dbg] Received command VM(RESUME), id=1790. [1260] Resuming vm... [2054] Resumed. [0410] Resumed. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event TYPE_LOAD, suspend=2. [0410] Suspended. [dbg] Received command TYPE(1), id=1791. [dbg] Received command TYPE(6), id=1792. [dbg] Received command VM(RESUME), id=1793. [2054] Received single step event for suspending. [2054] Suspended. [1260] Resuming vm... [0410] Resumed. [2054] Resumed. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event TYPE_LOAD, suspend=2. [0410] Suspended. [dbg] Received command TYPE(1), id=1794. [dbg] Received command TYPE(6), id=1795. [dbg] Received command VM(RESUME), id=1796. [1260] Resuming vm... [0410] Resumed. [0410] Breakpoint hit, method=Step, offset=0x1e. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event BREAKPOINT, suspend=2. [0410] Suspended. [dbg] Received command VM(ALL_THREADS), id=1797. [dbg] Received command THREAD(1), id=1798. Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... ___ Mono-devel
Re: [Mono-dev] Soft Debugger issues (can't suspend threads in wait_for_suspend)
Turns out it might be due to Win32 limitations (QueueUserAPC works only if SleepEx/WaitForMultipleObjectsEx etc... are used), as notify_thread_apc is never called back. I can fix that on my own threads. However, finalizer thread should use such functions as well otherwise it will always hang internally. Sorry for the trouble. On Wed, Jan 26, 2011 at 1:26 AM, Virgile Bello virgile.be...@gmail.comwrote: Sorry, last small update, if I simply disable the waiting loop in wait_for_suspend() and make is_suspended() always return TRUE, breakpoints/tracing work as expected (except maybe playing with other threads of course). This seems to confirm there might be some false positive when trying to detect threads that run in native mode (mono think they are managed). On Wed, Jan 26, 2011 at 1:06 AM, Virgile Bello virgile.be...@gmail.comwrote: Just as a small addition, to confirm what I said earlier concerning situation with additional threads. After adding 2 threads that don't actually call mono (simply register them with mono_thread_attach(mono_get_root_domain())), I end up having: Waiting for 2(4) threads to suspend... which mean 1 of the fully native threads is also blocking it. Maybe it can't detect well when threads are running in native mode? I will continue to investigate as well. On Wed, Jan 26, 2011 at 12:58 AM, Virgile Bello virgile.be...@gmail.comwrote: I am having trouble with mono soft debugger. - I embed Mono runtime in my program, and I got MonoDevelop to act as SoftDebugger client - Mono soft debugger is loading properly (first breakpoint usually works -- if already set beforehand -- I can see callstacks, etc...) - As soon as I press F5 -- to execute until this breakpoint is reached again next iteration -- or if I disable/reenable this breakpoint, program hang (see log) - Main loop is in C and Mono functions are called regularly. I traced down the problem to thread(s) not suspending (cf log). Usually, it seems it is the Finalizer thread (in this case 2054) that doesn't get suspended. In mono sources, I tried to call mono_gc_collect/mono_gc_invoke_finalizers in the suspend_thread loop. In that case, I can manage to have F5 working (breakpoint trigger every step inside the loop). However it doesn't work as soon as I do anything else (such as removing adding again the breakpoint). I remember seeing this problem on more than 1 thread when I had other threads active (i.e. Waiting for 3(4) threads to suspend...) Does anyone have an idea? Maybe there is something special to do if Mono doesn't keep hand (often back to full unmanaged world since main loop is in C) Debugger log: [0410] Thread started, obj=04702F20, tls=004CDA60. [0410] Suspended. [0410] Resumed. [0410] Suspending vm... [0410] Sent event VM_START, suspend=2. [0410] Suspended. [dbg] Agent thread started, pid=1260 [2054] Thread started, obj=04702E70, tls=004EC1D8. Finalizer thread [2054] Suspended. [dbg] Received command VM(VERSION), id=1. [dbg] Received command VM(SET_PROTOCOL_VERSION), id=2. [dbg] Protocol version 2.2, client protocol version 2.2. [dbg] Received command APPDOMAIN(1), id=3. ... [0410] Suspended. [dbg] Received command TYPE(1), id=1785. [dbg] Received command TYPE(6), id=1786. [2054] Received single step event for suspending. [2054] Suspended. [dbg] Received command VM(RESUME), id=1787. [1260] Resuming vm... [2054] Resumed. [0410] Resumed. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event TYPE_LOAD, suspend=2. [0410] Suspended. [dbg] Received command TYPE(1), id=1788. [dbg] Received command TYPE(6), id=1789. [2054] Received single step event for suspending. [2054] Suspended. [dbg] Received command VM(RESUME), id=1790. [1260] Resuming vm... [2054] Resumed. [0410] Resumed. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event TYPE_LOAD, suspend=2. [0410] Suspended. [dbg] Received command TYPE(1), id=1791. [dbg] Received command TYPE(6), id=1792. [dbg] Received command VM(RESUME), id=1793. [2054] Received single step event for suspending. [2054] Suspended. [1260] Resuming vm... [0410] Resumed. [2054] Resumed. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event TYPE_LOAD, suspend=2. [0410] Suspended. [dbg] Received command TYPE(1), id=1794. [dbg] Received command TYPE(6), id=1795. [dbg] Received command VM(RESUME), id=1796. [1260] Resuming vm... [0410] Resumed. [0410] Breakpoint hit, method=Step, offset=0x1e. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event BREAKPOINT, suspend=2. [0410] Suspended. [dbg] Received command VM(ALL_THREADS), id=1797. [dbg] Received command THREAD(1), id=1798. Waiting for 1(2) threads to suspend... Waiting
[Mono-dev] crash on first runtime_invoke (using MSVC build)
Recently, I had some problem with the VS2010 build of mono. Runtime check complains ESP is wrong after first time runtime_invoke is called. I traced it back to this single-line commit. (Reverting this single line avoids the problem on any version up to master) 08f0bcaad89540260323f24811cbf896cfe471ed Mark runtime invoke wrappers as pinvoke, since they are called from native code. diff --git a/mono/metadata/marshal.c b/mono/metadata/marshal.c index 476d129..c586555 100644 --- a/mono/metadata/marshal.c +++ b/mono/metadata/marshal.c @@ -4571,6 +4571,7 @@ mono_marshal_get_runtime_invoke (MonoMethod *method, gboolean virtual) csig-params [1] = mono_defaults.int_class-byval_arg; csig-params [2] = mono_defaults.int_class-byval_arg; csig-params [3] = mono_defaults.int_class-byval_arg; + csig-pinvoke = 1; name = mono_signature_to_name (callsig, virtual ? runtime_invoke_virtual : runtime_invoke); mb = mono_mb_new (target_klass, name, MONO_WRAPPER_RUNTIME_INVOKE); ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] crash on first runtime_invoke (using MSVC build)
It crashes with all apps during mono_jit_init[_version] (which use mono_runtime_invoke internally) mono-2.0.dll!mono_jit_runtime_invoke(_MonoMethod * method, void * obj, void * * params, MonoObject * * exc) Line 5700 C mono-2.0.dll!mono_runtime_invoke(_MonoMethod * method, void * obj, void * * params, MonoObject * * exc) Line 2727 + 0x18 bytes C mono-2.0.dll!create_exception_two_strings(_MonoClass * klass, _MonoString * a1, _MonoString * a2) Line 134 + 0x13 bytes C mono-2.0.dll!mono_exception_from_name_two_strings(_MonoImage * image, const char * name_space, const char * name, _MonoString * a1, _MonoString * a2) Line 157 + 0x11 bytes C mono-2.0.dll!create_domain_objects(_MonoDomain * domain) Line 177 + 0x1c bytes C mono-2.0.dll!mono_runtime_init(_MonoDomain * domain, void (int, void *, void *)* start_cb, void (int, void *)* attach_cb) Line 261 + 0x9 bytes C mono-2.0.dll!mini_init(const char * filename, const char * runtime_version) Line 6514 + 0x13 bytes C mono-2.0.dll!mono_jit_init_version(const char * domain_name, const char * runtime_version) Line 2043 + 0xd bytes C On Sat, Jan 15, 2011 at 9:20 AM, Zoltan Varga var...@gmail.com wrote: Hi, Do you have a testcase, or does this happen with all apps ? Zoltan On Fri, Jan 14, 2011 at 10:58 PM, Virgile Bello virgile.be...@gmail.comwrote: Recently, I had some problem with the VS2010 build of mono. Runtime check complains ESP is wrong after first time runtime_invoke is called. I traced it back to this single-line commit. (Reverting this single line avoids the problem on any version up to master) 08f0bcaad89540260323f24811cbf896cfe471ed Mark runtime invoke wrappers as pinvoke, since they are called from native code. diff --git a/mono/metadata/marshal.c b/mono/metadata/marshal.c index 476d129..c586555 100644 --- a/mono/metadata/marshal.c +++ b/mono/metadata/marshal.c @@ -4571,6 +4571,7 @@ mono_marshal_get_runtime_invoke (MonoMethod *method, gboolean virtual) csig-params [1] = mono_defaults.int_class-byval_arg; csig-params [2] = mono_defaults.int_class-byval_arg; csig-params [3] = mono_defaults.int_class-byval_arg; + csig-pinvoke = 1; name = mono_signature_to_name (callsig, virtual ? runtime_invoke_virtual : runtime_invoke); mb = mono_mb_new (target_klass, name, MONO_WRAPPER_RUNTIME_INVOKE); ___ 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
[Mono-dev] Mono Tasklets (microthread resuming with different stack, and possibly microthread migration)
I was wondering a few things concerning Mono.Taskets: 1/ By modifying mono to not throw an exception when marking top-most frame a second time (using Mono.Continuation.Mark), I figured more behavior could be covered. As an example, let's say I Mark and Store in the following stack frame: == Stack C2() - Here I Store(0) == Stack C1() - Here I Mark == Stack A2() == Stack A1() Next run, I could run B1 again from a different stack to restore B2: == Stack C2() - Here I Store(0) == Stack C1() - Here I Mark _again_ to update current stack topmost frame, and then Restore(0) which will add C2 on top of new stack == Stack B3() == Stack B2() == Stack B1() Basically, this enables Continuation to be resumed later in time, even if calling stack frame is different. As a result, MicroThread Scheduler could be rewritten so that it runs in a Step() mode every frame instead of a Run() loop (which force to create thread) This could even allow to migrate MicroThread on a different Thread (not tested yet). So far it seems to work on simple case, can anyone tell me if it could lead to any issues I could not foresee? I was especially worried about internal pointer to stack (if there is any) becoming invalid if base ESP gets shifted (but in that case, I could always manage to call this function with the same call stack so ESP would be the same between each Step()). 2/ I noticed a bug in continuation_mark_frame that could lead to random crash: https://bugzilla.novell.com/show_bug.cgi?id=659827 3/ So far it is only available on x86/ia64. Is there anything that would prevent it to work on other platform (esp. ARM/PS3 etc...) in the future? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Conflict between Mono.Debugger.Soft and .NET
As code inside both .NET VM is totally separate and won't reference each other, is it really a problem? So far, I could run code inside the embedded VM without any problem (main app is using MS VM for WPF, embedded inside PInvoke code is mono VM for user scripts, so code is totally separate, there should be no common DLL), only the breakpoint hook was problematic. Virgile On 2010/12/04, at 15:57, Zoltan Varga var...@gmail.com wrote: Hi, You are basically embedding the mono runtime inside the .net runtime, this will not work, not just debugging, but other stuff as well. Zoltan On Sat, Dec 4, 2010 at 4:53 AM, Virgile Bello virgile.be...@gmail.comwrote: Hello, I am embedding Mono VM from C++ using mono runtime API, and using Mono.Debugger.Soft to debug the code running inside the VM (for scripting purpose). I managed to make it work well (I receive TypeLoad MethodEntry events from debugger). However, I tried to embed this C++ code inside a .NET application through P/Invoke to make some tools with UI (layers are .NET/UI ==(pinvoke)== C++ engine ==(mono VM)== Mono scripting). In that configuration, the application crash as soon as it tries to run some VM code that should trigger a breakpoint/MethodEntry event, i.e. running a constructor (the debugger connect, and I receive AssemblyLoad and TypeLoad event before it crashes). Log shows everything is fine but suddenly stop at the time breakpoint is supposed to be caught. I suppose this is due to a conflict about how Mono try to catch the breakpoint (using interrupt or something like that) and the .NET layer which probably try to catch those events as well for internal reasons (failure detection, or to transmit some other information maybe). I was wondering if someone could think of a way to make .NET runtime not conflict with Mono debug breakpoints. Also, just so you know, Mono.Debugger.Soft.dll shipped with Mono 2.8.1 Windows doesn't work, I had to either recompile it or get the one from MonoDevelop. Virgile ___ 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
Re: [Mono-dev] Conflict between Mono.Debugger.Soft and .NET
I see, thanks for the details. I suppose I will probably need to separate process or redesign to share VM (I won't be able to have WPF UI and mono VM API at the same time tho). I will take a look if I can disable segfault handling for MS (enclosing) VM when running PInvoke code as well. The system/engine is supposed to run as C++ alone with mono embedded for it's scripts. Additional enclosing VM was only for designer/editing WPF UI tools calling directly this C++ API to run the engine. Virgile On 2010/12/04, at 18:18, Zoltan Varga var...@gmail.com wrote: Mono uses segmentation fault handling to implement both breakpoints/single stepping and null reference exception handling. MS.NET probably does the same, and the two can't coexist. If you embed your code inside the MS.NET VM anyway, why don't you use their vm for running this scripting code instead of mono ? Zoltan On Sat, Dec 4, 2010 at 10:01 AM, Virgile Bello virgile.be...@gmail.comwrote: As code inside both .NET VM is totally separate and won't reference each other, is it really a problem? So far, I could run code inside the embedded VM without any problem (main app is using MS VM for WPF, embedded inside PInvoke code is mono VM for user scripts, so code is totally separate, there should be no common DLL), only the breakpoint hook was problematic. Virgile On 2010/12/04, at 15:57, Zoltan Varga var...@gmail.com wrote: Hi, You are basically embedding the mono runtime inside the .net runtime, this will not work, not just debugging, but other stuff as well. Zoltan On Sat, Dec 4, 2010 at 4:53 AM, Virgile Bello virgile.be...@gmail.com virgile.be...@gmail.com wrote: Hello, I am embedding Mono VM from C++ using mono runtime API, and using Mono.Debugger.Soft to debug the code running inside the VM (for scripting purpose). I managed to make it work well (I receive TypeLoad MethodEntry events from debugger). However, I tried to embed this C++ code inside a .NET application through P/Invoke to make some tools with UI (layers are .NET/UI ==(pinvoke)== C++ engine ==(mono VM)== Mono scripting). In that configuration, the application crash as soon as it tries to run some VM code that should trigger a breakpoint/MethodEntry event, i.e. running a constructor (the debugger connect, and I receive AssemblyLoad and TypeLoad event before it crashes). Log shows everything is fine but suddenly stop at the time breakpoint is supposed to be caught. I suppose this is due to a conflict about how Mono try to catch the breakpoint (using interrupt or something like that) and the .NET layer which probably try to catch those events as well for internal reasons (failure detection, or to transmit some other information maybe). I was wondering if someone could think of a way to make .NET runtime not conflict with Mono debug breakpoints. Also, just so you know, Mono.Debugger.Soft.dll shipped with Mono 2.8.1 Windows doesn't work, I had to either recompile it or get the one from MonoDevelop. Virgile ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.comMono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list 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
[Mono-dev] MonoBind (C++ binding library) and runtime debugger for embedded mono.
Hi, I just wanted to let you know that I updated the monobind library, available at http://dev.kalimdor.org/entropia It's a C++ wrapper library for C# scripting (luabind/boost::python alike). Now it doesn't need mono to be patched anymore. What's left is auto-generating .cs headers, and embed mcs compiler to compile C# scripts on the fly with those .cs headers. Also, C# class wrapped on C++ side needs facilities (a base class to start from probably, or helper func). SWiG module for that could also be interesting. I will probably start a sf.net webpage for the project, please contact me if you're interested. Also, if people are interested, I started some time ago a debugger (more a proof of concept than a real project right now), that I could work on again. It allows C# tracing and variables inspection of C# code executed by Mono VM from C/C++ runtime. Do not hesitate to give me feedbacks on all that ! Thanks again, Virgile Bello ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting runtime - where to start?
Quoting Paolo Molaro [EMAIL PROTECTED]: On 04/03/07 [EMAIL PROTECTED] wrote: There is a tool to convert PE executable (with PPC code) in their .xex format. However, there were issues : 1/ AOT is working only on x86 right now, according to http://tirania.org/blog/archive/2006/Aug-17.html It also works on amd64. support for ppc would need to be added, but it is not a big issue. 2/ And even if it's ok, the more important problem is that according to the same post, it still need JIT at some place. Yes: we'd need a few changes to avoid jitting at all, but it is doable. It would really be nice ! Don't hesitate to let me know as soon as those two points are done and I'll give it a try. 3/ When working on it, I tried to produce PE file with PE PPC Big endian target with binutils, and it was really painful, it's not really supported anymore (I speak of PE format only of course, it's well supported in other cases). Currently the PE format would be generated by the assembler/linker. You'd need to write some code to be able to generate directly the PE binary file. Yep, anyway I think code is more or less done, it would just require some time to reactivate it. ReactOS project could be of some help here as they did the same thing (they had a binutils patch for ppc-pe). ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting runtime - where to start?
Quoting Paolo Molaro [EMAIL PROTECTED]: On 04/03/07 [EMAIL PROTECTED] wrote: Was anyone able to determine if the old XBOX (x86) emulator or the xbox 360 CLR runtime do any jitting? It would be very surprising if they didn't do it and if they did, the European Commission is very likely interested in how they do it (hint, hint:-). I think the XBOX 360 CLR runtime does JITing, but well, Microsoft got a better access to console internal than us. Sure, that's a good reason for the European commission to investigate why they still adopt anti-competitive practices. If they do jitting, other people developing for the platform should be allowed to have the info do it as well. Hopefully the game industry will pressure them as well. By the way, I sent yesterday a mail to MS in that sense. But well, we all know how it will end :) The XBOX360 changes are pointless since it seems not possible to make it working. There is definitely interest and it is likely possible to make it work using the AOT backend and the PE file converter you mentioned, so I don't think the changes are pointless: they will enable other interested people to help you with your efforts. If you have other reasons that prevent you from contributing the code that's understandable. No, that's no problem for me to release it (still it would need some polishing before doing so). However, I also had to port glibc first, so it's kinda messy. What I dont know is if it's legal to release code using this xdk, since it's not available for public... (even headers). I'll ask and let you know. About the debugger, it's more a prototype right now, but I will probably work on it again if the code to get my monobind wrapper working is included in mono source tree (I posted the patch at http://lists.ximian.com/pipermail/mono-devel-list/2007-March/022949.html, I dunno if it was the right place for that). I'll review it in a bit, I was on vacation the last few days. Nevertheless, if it never happens, I might drop the sources of that prototype as a base (I nearly managed to do singlestepping and variable inspection with class definition extracted from runtime context). Did you check the mono*describe* functions in metadata/class-internals.h? Yes, that's what I use if I remember right. Introspection is done with mono api itself (and that's why it is nice ! ;p). ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] MonoBind - C++ bindings library [include Mono Patch]
Quoting Paolo Molaro [EMAIL PROTECTED]:
On 03/28/07 [EMAIL PROTECTED] wrote:
As I worked on a C++ binding library for mono, very close to
boost::python/luabind syntax, I had few minor modification to do in Mono
sources. The patch is attached.
I was wondering if it was possible to include them in mono.
The missing thing was the possibility to bind a pointer argument to an
internal
call. It is required in order to make all the C++ wrapper/proxy statically
linked through template metaprogramming.
[...]
Later, I would like the registration code to auto-generate C# header.
I think auto-generation is the only option, unless this is supposed to
be used for very few classes.
Anyway, I took a look at the code, but I don't see a reason why the core
of mono would need changes for this, you can do it all without any
mono changes.
What you basically are doing is that, given a icall method declaration,
to actually call a function with a different signature. Why not use the
correct signature in the first place?
[C code (or C-representation of the C++ ABI?)]
void icall (void *this_ptr, void *hidden_arg, int a);
[Old C# code: mono core changes needed because the signature is incorrect]
[MethodImplAttribute(MethodImplOptions.InternalCall)]
extern public void Test (int a);
[New C# code: no core mono changes needed]
[MethodImplAttribute(MethodImplOptions.InternalCall)]
extern void Test (IntPtr hidden_arg, int a);
static readonly IntPtr Test_hidden_arg;
public void Test (int a) {
Test (Test_hidden_arg, a);
}
And you will initialize Test_hidden_arg as part of the binding startup
code with the embedding API or even with an icall in C#:
static readonly IntPtr Test_hidden_arg = MonoBind.CreateSig (vi);
where vi means void for the return type and i is the first argument of
type int, though there are also other options, like (using params arrays):
static readonly IntPtr Test_hidden_arg = MonoBind.CreateSig (null,
typeof
(int));
This makes it much more flexible and also much easier to deal with if
you automatically generate the C# side.
Yes you're right, that's the first approach I took. It's just I felt it was
cleaner to do it the other way. But well, since those definitions are
auto-generated I suppose it's not a big deal doubling everything.
Thanks for the review.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting runtime - where to start?
Quoting Paolo Molaro [EMAIL PROTECTED]: On 03/31/07 [EMAIL PROTECTED] wrote: The problem of AOT is that it only generates .so (or .dll on Win32 platform I guess). Nevertheless, XBOX executable format, .xex, has to go through their special compilator. So, no other way that I know than getting C++ code to compile. Don't they provide some tool to create an executable from assembly code? If that is possible you could tweak the code to use that. Or, if the file format is documented or easy to understand, you could change the binary writer AOT code to emit it directly. lupus Ok, I took a look at all that. There is a tool to convert PE executable (with PPC code) in their .xex format. However, there were issues : 1/ AOT is working only on x86 right now, according to http://tirania.org/blog/archive/2006/Aug-17.html 2/ And even if it's ok, the more important problem is that according to the same post, it still need JIT at some place. 3/ When working on it, I tried to produce PE file with PE PPC Big endian target with binutils, and it was really painful, it's not really supported anymore (I speak of PE format only of course, it's well supported in other cases). ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting runtime - where to start?
Quoting Paolo Molaro [EMAIL PROTECTED]: On 03/30/07 [EMAIL PROTECTED] wrote: Just to let you know since I did something very similiar for XBOX360 : Even if I was able to make glib and then mono compile on XBOX360 (it was a bit painful but doable) and it generated valid code to execute at runtime, nevertheless memory protection against execution of user allocated area totally prevented me to continue (you can check the blog post I did about that on http://dev.kalimdor.org/entropia/). Was anyone able to determine if the old XBOX (x86) emulator or the xbox 360 CLR runtime do any jitting? It would be very surprising if they didn't do it and if they did, the European Commission is very likely interested in how they do it (hint, hint:-). I think the XBOX 360 CLR runtime does JITing, but well, Microsoft got a better access to console internal than us. In the blob you talk about the xbox 360 changes and about a mono debugger. Can you tell us more about that? Are you able to contribute those changes for inclusion in mono? Thanks! lupus The XBOX360 changes are pointless since it seems not possible to make it working. About the debugger, it's more a prototype right now, but I will probably work on it again if the code to get my monobind wrapper working is included in mono source tree (I posted the patch at http://lists.ximian.com/pipermail/mono-devel-list/2007-March/022949.html, I dunno if it was the right place for that). Nevertheless, if it never happens, I might drop the sources of that prototype as a base (I nearly managed to do singlestepping and variable inspection with class definition extracted from runtime context). ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting runtime - where to start?
Quoting Miguel de Icaza [EMAIL PROTECTED]: Hello, When I checked about using the interpreter, I've read somewhere that it wasn't up to date anymore (maybe the info was too old and it's now up to date to execute everything, anyone can confirm ?). It still builds, but no maintenance has gone into it. It is also missing important things like generics support, that was never updated. But the main problem you have with the interpreter is that the interpreter *also* needs to generate dynamic code. All the trampoline code is emitted at runtime so you need to have that. Ok, thanks for the summary of its current state issues. So in short: the interpreter just generates *less* code than the JIT, but it still generates code. I heard from an embedded customer of ours that they are looking at pregenerating all the trampoline code but am not sure this is a long term strategy. It could be very promising ! Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting runtime - where to start?
As of December XDK it wasn't possible. I checked doc of february one and it was still the same, and I'm downloading april one right now to check doc if anything changed (though nothing changed according to release note). Btw, when I asked, it was also confirmed on xbox mailing list by microsoft people that it was designed to be impossible to do that. I really hope they change it ! (even if it requires some protection security scheme). Best would be a partnership with XBOX and Mono... Well, just kidding of course ! Sincerely Virgile Bello Quoting Miguel de Icaza [EMAIL PROTECTED]: Hello, prevented me to continue (you can check the blog post I did about that on http://dev.kalimdor.org/entropia/). I read somewhere that some of those restrictions were being lifted, am I incorrect? Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting runtime - where to start?
The problem of AOT is that it only generates .so (or .dll on Win32 platform I guess). Nevertheless, XBOX executable format, .xex, has to go through their special compilator. So, no other way that I know than getting C++ code to compile. Quoting Miguel de Icaza [EMAIL PROTECTED]: Hello, Just to let you know since I did something very similiar for XBOX360 : Even if I was able to make glib and then mono compile on XBOX360 (it was a bit painful but doable) and it generated valid code to execute at runtime, nevertheless memory protection against execution of user allocated area totally prevented me to continue (you can check the blog post I did about that on http://dev.kalimdor.org/entropia/). Another thing that am wondering is whether precompilation (AOT) might be enough to use Mono on those consoles. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting runtime - where to start?
Just to let you know since I did something very similiar for XBOX360 : Even if I was able to make glib and then mono compile on XBOX360 (it was a bit painful but doable) and it generated valid code to execute at runtime, nevertheless memory protection against execution of user allocated area totally prevented me to continue (you can check the blog post I did about that on http://dev.kalimdor.org/entropia/). When I checked about using the interpreter, I've read somewhere that it wasn't up to date anymore (maybe the info was too old and it's now up to date to execute everything, anyone can confirm ?). So, before going on, check that either the console can run unsigned code loaded in memory (which I doubt since they tend to avoid that, since it would quickly run into hacking of the console) or that mono interpreter is now working again. Hope that helps, do not hesitate if you would like some other infos. Cordially, Virgile Quoting John Matzen [EMAIL PROTECTED]: I'm trying to port the mono runtime to a device called a Wii. Although it has a PowerPC based CPU, I think getting it running with the interpreter first would be the best approach rather than attempting to patch up the existing PowerPC JIT, but I can not seem to find any documentation that would describe how to begin fixing up the build system so that I can compile it with the Wii's build tools (which are not gcc based). Any ideas on where to start? Thanks! John ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] MonoBind - C++ bindings library [include Mono Patch]
Hello, As I worked on a C++ binding library for mono, very close to boost::python/luabind syntax, I had few minor modification to do in Mono sources. The patch is attached. I was wondering if it was possible to include them in mono. The missing thing was the possibility to bind a pointer argument to an internal call. It is required in order to make all the C++ wrapper/proxy statically linked through template metaprogramming. (The only other possibility of doing it, using pointer to function member removed the possibility to deduce type of function arguments, resulting in a heavy syntax when declaring exported class in C++). You can check the binding library at : http://dev.kalimdor.org/entropia/node/10 It's still in development (like there is few non trivial to fix memory leak, i.e. the wrapping code that should stay alive when mono is running), but right now it works fine at exporting C++ class to C# and C# class to C++. Later, I would like the registration code to auto-generate C# header. By the way, I still have a mono debugger for embedded mono (more or less in pause, but if lot of people are interested in it, I could start working on it again). I think with all that Mono could be a really great scripting language, offering blazing speed compared to all the usual non-JIT script languages, with all the advantages of C#. Sincerely, Virgile Bello mono_internal_call_param.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] MonoBind - C++ bindings library [include Mono Patch]
Thanks for your comments ! Yes you're right, I didn't put any license, but I will very likely put it with an unrestrictive license, not sure of which one yet (BSD, zlib, LGPL, etc...). And I should make a real project page for it if some people start using it or contributing, that would look more serious. Virgile Quoting Cody Russell [EMAIL PROTECTED]: This is fantastic! I had just been working on my own C++ binding in the spirit of Boost-Python, but I think mine is not quite as far along as yours so I'll gladly drop it and use yours. Can you please tell us what the license is for yours though? It doesn't seem to say on the webpage or in the source files. / Cody On Wed, 2007-03-28 at 23:24 +0200, [EMAIL PROTECTED] wrote: Hello, As I worked on a C++ binding library for mono, very close to boost::python/luabind syntax, I had few minor modification to do in Mono sources. The patch is attached. I was wondering if it was possible to include them in mono. The missing thing was the possibility to bind a pointer argument to an internal call. It is required in order to make all the C++ wrapper/proxy statically linked through template metaprogramming. (The only other possibility of doing it, using pointer to function member removed the possibility to deduce type of function arguments, resulting in a heavy syntax when declaring exported class in C++). You can check the binding library at : http://dev.kalimdor.org/entropia/node/10 It's still in development (like there is few non trivial to fix memory leak, i.e. the wrapping code that should stay alive when mono is running), but right now it works fine at exporting C++ class to C# and C# class to C++. Later, I would like the registration code to auto-generate C# header. By the way, I still have a mono debugger for embedded mono (more or less in pause, but if lot of people are interested in it, I could start working on it again). I think with all that Mono could be a really great scripting language, offering blazing speed compared to all the usual non-JIT script languages, with all the advantages of C#. Sincerely, Virgile Bello ___ 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
