Re: [Mono-dev] Compiling Mono v2.4 RC2 (Solaris 10 SPARCv9)
Last one I tried and build was 2.2. We're using it to test Plastic every week on OpenSolaris. The binaries are available at Blastwave, but never tried 2.4 Jonathan Soft escribió: I'm reaching the conclusion that Mono v2.4 does not work on Solaris 10 SPARC - this is based on both my own unsuccessful attempts to build and run it (or debug it, for that matter), and on the non existence of reports on the web indicating 2.4 success on the Solaris SPARC platform. Giving up for now. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono on XScale-PXA255r6
Hello, I tested last daily build (http://mono.ximian.com/daily/mono-20090414.tar.bz2) for ARM_FPU_NONE, ARM_FPU_FPA and ARM_FPU_VFP and result is difference = still same = Glib-CRITICAL **: g_hash_table_insert (or g_hash_table_lookup): assertion 'hash_table!=NULL' failed In previous tests was bug only in single values (double works fine), but now all tests completly don't work. Regards, Tom -- View this message in context: http://www.nabble.com/Mono-on-XScale-PXA255r6-tp22970401p23055287.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Use eglib as a default for mono 2.6
Hi, Can you guys please switch to eglib as the default across the board, so that this codepath gets properly tested in the real world. We need to move towards using a single mono source base for all our platforms and relying on external dependencies in mono is a lot of pain when we try to build mono. I asked if that could be done for mono 2.4 and it was too late for that, I understand. But could you guys please fix this for mono 2.6. It would really make a big difference for us. Joachim Ante ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Monoco, couroutines and Mono.
Hi, On Tue, 14 Apr 2009, James Mansion wrote: Tomi Valkeinen wrote: And I'm still of the opinnion that this stack-copying is more of an interesting hack, than something people should really use =). Is there a real cast-in-stone reason why a VM engine has to have a contiguous stack at the point where a hardware thread calls into the coroutine scheduler and is scheduled onto a coroutine? I think you mean OS thread. The coroutines are nothing special, they are similar to any other jitted code that mono produces. And thus the stack has to be the normal continuous OS stack. I believe it could be possible to rewrite the whole jit code generation to produce code that doesn't use stack but position independent frames, and then these frames could be used to create much faster continuations without any copying (like stackless python). But this would mean that the frame could not grow dynamically, and I bet there are other limitations which makes this solution not compatible with how CLI is supposed to work. And it would be a huge job =). Tomi ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] ..mscorlib.dll was not found compiling mono from sources
Hi, Please, someone??, I'm following the official instruction (and other sugestions to) to try to compile mono (to later be able to compile MD with the debugger addins..)..and no matter what options I use in the configuration (--with-doc=no, ---disable-preview ...and others) and allways stop with the same error!!?? make[2]: Leaving directory `/media/data/opt/monosvn/mono/msvc' Making all in docs make[2]: Entering directory `/media/data/opt/monosvn/mono/docs' cd . make -f docs.make topdir=../../mcs convert.exe make[3]: Entering directory `/media/data/opt/monosvn/mono/docs' MCS [default] convert.exe The assembly mscorlib.dll was not found or could not be loaded. It should have been installed in the `/opt/mono/lib/mono/1.0/mscorlib.dll' directory. make[3]: *** [convert.exe] Error 1 I'm not trying something *fancy*, this is NOT a mono compilation for iphone, or sparc64, is standard x86 fedora 10 notebook, please tell me that is posible to compile and use mono + MD + debugger addins outside OpenSuse ... Thanks Mauricio Peter Alfredsen wrote: On Tue, 14 Apr 2009 11:47:36 -0400 buhochil...@gmail.com buhochil...@gmail.com wrote: ## DebuggerServer started EXCEPTION: Mono.Debugger.TargetException: Unsupported `mono' executable: /usr/bin/mono I hadn't even read this email when I replied in the other thread, but that is the exact message we were getting in Gentoo from mono-debugger when Mono was compiled with --disable-static. /loki_val ___ 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] ..mscorlib.dll was not found compiling mono from sources
Toshio Kuratomi wrote: buhochil...@gmail.com wrote: Hi, Please, someone??, I'm following the official instruction (and other sugestions to) to try to compile mono (to later be able to compile MD with the debugger addins..)..and no matter what options I use in the configuration (--with-doc=no, ---disable-preview ...and others) and allways stop with the same error!!?? make[2]: Leaving directory `/media/data/opt/monosvn/mono/msvc' Making all in docs make[2]: Entering directory `/media/data/opt/monosvn/mono/docs' cd . make -f docs.make topdir=../../mcs convert.exe make[3]: Entering directory `/media/data/opt/monosvn/mono/docs' MCS [default] convert.exe The assembly mscorlib.dll was not found or could not be loaded. It should have been installed in the `/opt/mono/lib/mono/1.0/mscorlib.dll' directory. make[3]: *** [convert.exe] Error 1 I'm not trying something *fancy*, this is NOT a mono compilation for iphone, or sparc64, is standard x86 fedora 10 notebook, please tell me that is posible to compile and use mono + MD + debugger addins outside OpenSuse ... Have you taken a look at the Fedora packages? Fedora-10 has mono-2.2 and monodebugger argh, as I explain in all my post, the goal is have the monodevelop debugger addins, so yes I know about the fedora 10 and koji fedora 11 packages, but those don't include the monodevelop debugger addins. Also as I explain in a later post, is posible to compile just monodevelop using the mono core installed by the f11 koji packages, but the monodevelop debugger addins don't work and claims about: ## DebuggerServer started EXCEPTION: Mono.Debugger.TargetException: Unsupported `mono' executable: /usr/bin/mono So, probably the RPM guys seems to be compiling mono core in some way that make imposible for the debugger addin to work... So what are my options?, try to to compile ALL by mysefl to no depend on koji things...but here is where the mscorlib problem came in... I've just finished building mono-2.4 for Fedora-11 which might have additional things that are necessary if you're building from mono's trunk. By the way, this is a question about the mscorlib problem compiling mono, I'm pretty tired about the fedora support for mono, so please don't tell me to wait until something that is going to come for fedora and things that might have, I prefer to try to solve directly the compilation things and posible make my own paquages for the Univ. http://cvs.fedoraproject.org/viewvc/rpms/mono/ -Toshio Thanks anyway... Mauricio ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Performance problems on ARM/linux
Robert Jordan wrote: It should be possible to import symbols from the main module (mono) by applying the __Internal special dll name: [DllImport (__Internal)] static extern ... WaitForSingleObject(...) So you can get rid of the less tested --without-static_mono. Robert Thank you, I didn't know about that. Unfortunately it doesn't seem to work. Using __Internal I don't need a mapping in the config file anymore but it can't find the symbols: (lenny)mfuz...@mfuzzey-laptop:~/work/linux/mx21/mono/cs-src$ MONO_LOG_LEVEL=info MONO_LOG_MASK=dll mono testsys.exe Mono-INFO: DllImport attempting to load: '__Internal'. Mono-INFO: Searching for 'CreateEvent'. Mono-INFO: Probing 'CreateEvent'. Mono-INFO: Probing 'CreateEvent'. Mono-INFO: Probing 'CreateEventA'. Mono-INFO: Probing 'CreateEventA'. Mono-INFO: DllImport attempting to load: '__Internal'. Mono-INFO: Searching for 'GetCurrentThread'. Mono-INFO: Probing 'GetCurrentThread'. Mono-INFO: Probing 'GetCurrentThread'. Mono-INFO: Probing 'GetCurrentThreadA'. Mono-INFO: Probing 'GetCurrentThreadA'. Started Mono-INFO: DllImport attempting to load: '__Internal'. Mono-INFO: Searching for 'CreateEvent'. Mono-INFO: Probing 'CreateEvent'. Mono-INFO: Probing 'CreateEvent'. Mono-INFO: Probing 'CreateEventA'. Mono-INFO: Probing 'CreateEventA'. Unhandled Exception: System.EntryPointNotFoundException: CreateEvent at (wrapper managed-to-native) Test:CreateEventDLL (intptr,bool,bool,string) at Test.go () [0x0] at Test.Main () [0x0] Looking at the code I think its because mono is doing a dlopen(NULL) then dlsym() However objdump shows that the symbols CreateEvent etc are not dynamic (they are listed with -t rather than -T) I get the same behaviour with both a x86 and an arm build. Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] ..mscorlib.dll was not found compiling mono from sources
buhochil...@gmail.com wrote: Toshio Kuratomi wrote: Have you taken a look at the Fedora packages? Fedora-10 has mono-2.2 and monodebugger argh, as I explain in all my post, the goal is have the monodevelop debugger addins, so yes I know about the fedora 10 and koji fedora 11 packages, but those don't include the monodevelop debugger addins. Also as I explain in a later post, is posible to compile just monodevelop using the mono core installed by the f11 koji packages, but the monodevelop debugger addins don't work and claims about: ## DebuggerServer started EXCEPTION: Mono.Debugger.TargetException: Unsupported `mono' executable: /usr/bin/mono So, probably the RPM guys seems to be compiling mono core in some way that make imposible for the debugger addin to work... That's a possibility. Do you know what configure switch would do that? So what are my options?, try to to compile ALL by mysefl to no depend on koji things...but here is where the mscorlib problem came in... Sure. So if you have a problem compiling mono itself and the rpm guys are getting mono itself to compile on the platform you're interested in, you should take a look at what they're doing. You can see what sequence of commands they're using to compike, what configure options they're giving, and what patches they're applying. Then you can make sure you don't apply whatever it is that's causing mono-debugger to malfunction while finding out how they are able to build. I've just finished building mono-2.4 for Fedora-11 which might have additional things that are necessary if you're building from mono's trunk. By the way, this is a question about the mscorlib problem compiling mono, I'm pretty tired about the fedora support for mono, so please don't tell me to wait until something that is going to come for fedora and things that might have, I prefer to try to solve directly the compilation things and posible make my own paquages for the Univ. I'm not doing that at all. I'm telling you -- if you have a problem compiling the mono package on Fedora; there's a repeatable recipe for getting mono to compile on Fedora in existence. Comparing it to what you're doing will help you find out what you're missing. BTW, if you get this to work, the monodevelop packager in Fedora would likely be interested in a bug report. If the problem is a configure switch to the mono build, you can email me and I'll get it in. -Toshio signature.asc Description: OpenPGP digital signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] ..mscorlib.dll was not found compiling mono from sources
Hi again, Toshio Kuratomi wrote: buhochil...@gmail.com wrote: Toshio Kuratomi wrote: Have you taken a look at the Fedora packages? Fedora-10 has mono-2.2 and monodebugger argh, as I explain in all my post, the goal is have the monodevelop debugger addins, so yes I know about the fedora 10 and koji fedora 11 packages, but those don't include the monodevelop debugger addins. Also as I explain in a later post, is posible to compile just monodevelop using the mono core installed by the f11 koji packages, but the monodevelop debugger addins don't work and claims about: ## DebuggerServer started EXCEPTION: Mono.Debugger.TargetException: Unsupported `mono' executable: /usr/bin/mono So, probably the RPM guys seems to be compiling mono core in some way that make imposible for the debugger addin to work... That's a possibility. Do you know what configure switch would do that? acording to a post in the list, guys are having simillar problems when mono is compiled with --disable-static, do you know if is used when the fedora rpm packages are compiled/created? So what are my options?, try to to compile ALL by mysefl to no depend on koji things...but here is where the mscorlib problem came in... Sure. So if you have a problem compiling mono itself and the rpm guys are getting mono itself to compile on the platform you're interested in, you should take a look at what they're doing. You can see what sequence of commands they're using to compike, what configure options they're giving, and what patches they're applying. Then you can make sure you don't apply whatever it is that's causing mono-debugger to malfunction while finding out how they are able to build. yeap I'm looking at he link that you send me to check that... I've just finished building mono-2.4 for Fedora-11 which might have additional things that are necessary if you're building from mono's trunk. By the way, this is a question about the mscorlib problem compiling mono, I'm pretty tired about the fedora support for mono, so please don't tell me to wait until something that is going to come for fedora and things that might have, I prefer to try to solve directly the compilation things and posible make my own paquages for the Univ. I'm not doing that at all. I'm telling you -- if you have a problem compiling the mono package on Fedora; there's a repeatable recipe for getting mono to compile on Fedora in existence. Comparing it to what you're doing will help you find out what you're missing. sorry if I sound to hard, but honestly I'm pretty tired about the poor support of fedora for the mono things, I also offer me and my Univ help to some of the koji packages guys, but they don't take it... BTW, if you get this to work, the monodevelop packager in Fedora would likely be interested in a bug report. If the problem is a configure switch to the mono build, you can email me and I'll get it in. surely... -Toshio Thanks Toshio Mauricio ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] {kinda OT} Linux equivalent of Win32 ReadProcessMemory...
On Tue, 2009-04-14 at 18:02 -0400, Mike Edenfield wrote: I eventually figure that out, it was the source of my seemingly random ESRCH errors trying to read from /proc/pid/mem. Once I realized that I need to PTRACE_ATTACH first, I was all set. I am successfully reading memory from my target process. So far, I've only managed to pull the ELF header out of memory, but it's a start. I just need to find a way to tell the difference between each possible version of the binary I might run into; the original utility relied on the fact that Windows linkers stick a time stamp into the PE header at creation time, but I don't see anything similar in ELF. What do you want to read from the process ? If you're just interested in the executable, you can also read /proc/PID/exe. If you just need a timestamp, you may check /proc/PID/exe, which is a symbolic link to the ELF file, and check its creation time. -- Martin Baulig - mar...@novell.com Novell GmbH, Nördlicher Zubringer 9-11, 40470 Düsseldorf GF: Dr. Jürgen Müller, Sylvia Geil, Felix Imendörffer; HRB 21108 (AG Düsseldorf) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting Mono Debugger to OSX
On Tue, 2009-04-14 at 20:21 +0200, jonas echterhoff wrote: But, now I'm wondering, how setting of breakpoints should work. When I launch mdb, set some breakpoints like b Y.Test, and then run, that causes OperationActivateBreakpoints and OperationInsertBreakpoint operations to be executed, which call the function debugger_insert_source_breakpoint inside mono. But, the breakpoints never seem to be actually set (no calls to server_ptrace_insert_breakpoint). How is this supposed to be invoked? Hi, When inserting managed breakpoints, the method is usually not JITed at the time we insert the breakpoint, so we don't have any address for it yet. In addition to that, there may be more than one address for each managed breakpoint - this happens when using multiple AppDomains. Because of this, the JIT sends the debugger a notification each time a method containing a breakpoint is compiled - see `NotificationType.JitBreakpoint' in Notification() in languages/mono/MonoLanguageBackend.cs. Here, the debugger performs a symbol table lookup and then actually inserts the breakpoint using server_ptrace_insert_breakpoint(). We need to do the symbol table lookup because we're usually not inserting the breakpoint on the first instruction of the method, but on some source line. Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] GO-MONO.COM is moving
Folks, We are in the process of moving go-mono.com to a new machine. I've tried to make sure all the pages we host there work just fine and the transition is smooth. Anyway, if you see anything wrong with the server within the next few hours, join #mono at irc.gimpnet.org and let me know. Thanks. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] ..mscorlib.dll was not found compiling mono from sources
buhochil...@gmail.com wrote: Hi again, Toshio Kuratomi wrote: buhochil...@gmail.com wrote: Toshio Kuratomi wrote: Have you taken a look at the Fedora packages? Fedora-10 has mono-2.2 and monodebugger argh, as I explain in all my post, the goal is have the monodevelop debugger addins, so yes I know about the fedora 10 and koji fedora 11 packages, but those don't include the monodevelop debugger addins. Also as I explain in a later post, is posible to compile just monodevelop using the mono core installed by the f11 koji packages, but the monodevelop debugger addins don't work and claims about: ## DebuggerServer started EXCEPTION: Mono.Debugger.TargetException: Unsupported `mono' executable: /usr/bin/mono So, probably the RPM guys seems to be compiling mono core in some way that make imposible for the debugger addin to work... That's a possibility. Do you know what configure switch would do that? acording to a post in the list, guys are having simillar problems when mono is compiled with --disable-static, do you know if is used when the fedora rpm packages are compiled/created? Yes, that is used. If that's all that's needed, you should be able to use anything else in the Fedora SRPM that looks like it will help get the build working. Just leaving out that flag from the configure line:: %configure --with-ikvm=yes --with-jit=yes --with-xen_opt=yes \ --with-moonlight=no --with-preview=yes --with-libgdiplus=installed \ #--disable-static sorry if I sound to hard, but honestly I'm pretty tired about the poor support of fedora for the mono things, I also offer me and my Univ help to some of the koji packages guys, but they don't take it... Yeah. Fedora's core competency is really C and Python with subcommunities that take care of perl, mono, java, php, ocaml, etc. The mono subcommunity is small and thus easily affected by the decisions of just a few people. That's good when they're making good decisions and bad when they're making poor ones. -Toshio signature.asc Description: OpenPGP digital signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Performance problems on ARM/linux
Rodrigo Kumpera wrote: Which FP mode your cpu/linux support? FPA, VFP or soft-float? ARM_FPU_NONE enables soft-float mode, which is super slow compared to any hardware. I'm using build option ARM_FPU_FPA however the hardware itself doesn't have a FPU so the kernel is doing the emulation. I think ARM_FPU_NONE uses a pure userspace implementation which should be faster than trapping illegal instructions and emulating in the kernel. Unfortunately that doesn't work as I indicated (problem with floats but not doubles). That said I don't think the performance problems stem from FP - it's not a number crunching app. In fact the application doesn't directly use FP at all though some of the system libraries (like hastable) do. Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] InternalsVisibleTo for MoonAtkBridge
This patch adds InternalsVisibleTo on the 2_1 profile, but using an env var for now until we assure that this is not a security threat. May I commit? Thanks. Andrés -- Index: class/corlib/Makefile === --- class/corlib/Makefile (revision 131333) +++ class/corlib/Makefile (working copy) @@ -25,6 +25,12 @@ corlib_flags = -unsafe -nostdlib LOCAL_MCS_FLAGS = -nowarn:612,618 -d:INSIDE_CORLIB +# this hack will be dropped once we get this working: +# http://www.mono-project.com/Moonlight/SecurityStatus#Assembly_Loading +ifdef MOON_A11Y_INTERNAL_HACK + MCS_FLAGS += -define:MOON_A11Y_INTERNAL_HACK +endif + # System.IO/DirectoryInfoTest.cs needs Mono.Posix TEST_MCS_FLAGS = -debug+ -debug:full -nowarn:168,219,618,672 -unsafe -r:$(topdir)/class/lib/$(PROFILE)/Mono.Posix.dll -define:MONO_DATACONVERTER_STATIC_METHODS Index: class/corlib/Assembly/AssemblyInfo.cs === --- class/corlib/Assembly/AssemblyInfo.cs (revision 131333) +++ class/corlib/Assembly/AssemblyInfo.cs (working copy) @@ -92,3 +92,12 @@ [assembly: InternalsVisibleTo (System.Net, PublicKey=00240480940006020024525341310004010001008D56C76F9E8649383049F383C44BE0EC204181822A6C31CF5EB7EF486944D032188EA1D3920763712CCB12D75FB77E9811149E6148E5D32FBAAB37611C1878DDC19E20EF135D0CB2CFF2BFEC3D115810C3D9069638FE4BE215DBF795861920E5AB6F7DB2E2CEEF136AC23D5DD2BF031700AEC232F6C6B1C785B4305C123B37AB)] [assembly: InternalsVisibleTo (System.Runtime.Serialization, PublicKey=00240480940006020024525341310004010001008D56C76F9E8649383049F383C44BE0EC204181822A6C31CF5EB7EF486944D032188EA1D3920763712CCB12D75FB77E9811149E6148E5D32FBAAB37611C1878DDC19E20EF135D0CB2CFF2BFEC3D115810C3D9069638FE4BE215DBF795861920E5AB6F7DB2E2CEEF136AC23D5DD2BF031700AEC232F6C6B1C785B4305C123B37AB)] #endif + +#if NET_2_1 + +// this hack will be dropped once we get this working: +// http://www.mono-project.com/Moonlight/SecurityStatus#Assembly_Loading + MOON_A11Y_INTERNAL_HACK + + [assembly: InternalsVisibleTo (MoonAtkBridge, PublicKey=002404809400060200245253413100040100010071eb6c5575529cbf7244f7a6ea056284f9eae03bcff2cc132c9c490ab309eab0b56bce449df503d9c0a81e520585cdbe70e2fb90434bac04fa6222a80098b7a1a7b3af991a412324bb4325f6b865bb64ebf6d1c206d5732ddfbc70a7389ee53e0c246e3279741ad00503e49842e19bf37b198b402126cb3689c2ea6496a47cb4)] +#endif ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting Mono Debugger to OSX
On Apr 15, 2009, at 6:43 PM, Martin Baulig wrote: On Tue, 2009-04-14 at 20:21 +0200, jonas echterhoff wrote: But, now I'm wondering, how setting of breakpoints should work. When I launch mdb, set some breakpoints like b Y.Test, and then run, that causes OperationActivateBreakpoints and OperationInsertBreakpoint operations to be executed, which call the function debugger_insert_source_breakpoint inside mono. But, the breakpoints never seem to be actually set (no calls to server_ptrace_insert_breakpoint). How is this supposed to be invoked? We need to do the symbol table lookup because we're usually not inserting the breakpoint on the first instruction of the method, but on some source line. Thanks. I installed a Linux VM now, which lets me run the debugger on linux to see how things should work, that makes life much easier. The reason breakpoints weren't working was that in order to set up a breakpoint, code needs to be executed inside the inferior executable's stack - which is normally execute protected in OS X. For now, I fixed this by marking all memory pages I write to as executable - which fixes the problem. Now the debugger actually starts working, sort of. I can set breakpoints, single-step through code, etc. Sure, there is still a lot to do, but actually seeing first results sure is nice. I will try to clean up the code and send a first patch tomorrow. How does the patch submission process actually work? I'm sure it's documented somewhere, but I couldn't find anything after a quick look on the web site. jonas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] {kinda OT} Linux equivalent of Win32 ReadProcessMemory...
On 4/15/2009 12:33 PM, Martin Baulig wrote: What do you want to read from the process ? If you're just interested in the executable, you can also read /proc/PID/exe. If you just need a timestamp, you may check /proc/PID/exe, which is a symbolic link to the ELF file, and check its creation time. Most of what I'm interested in is actual runtime data from the heap -- large arrays of objects tracking the state of all of the units in the game. The timestamp is used just to distinguish versions of the binary from each other, in case the memory layout changes. So far, for all of the native Linux versions I have access to, the ELF Header e_entry has been slightly different, so I'm going with that. Currently I can read the ELF data from /proc/PID/mem (through a FileStream) with no problem, but when I try to .Seek() to live data I get an Invalid handle error, even though I'm using the same instance of FileStream I just successfully read from. My suspicion is that the address being passed around are somehow invalid and I'll need to figure out how to fix them up. But thanks to this list I'm making far more progress than I expected in just a few days :) --Mike ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Monoco, couroutines and Mono.
Tomi Valkeinen wrote: I think you mean OS thread. The coroutines are nothing special, they are similar to any other jitted code that mono produces. Well, except that the core has some knowledge of them now, right? And thus the stack has to be the normal continuous OS stack. Thus? Why? You probably need to pin stack areas, but why can't you malloc (or mmap) some new space and place a stack in it? I think you'll find that Steve Dekorte's libcoro does that. If you are prepared to forgo guard pages and the like (or roll your own handler) then I don't see why the stack pointer absolutely has to be where you expect. And in fact the gubbins that normally gets pushed to the main CPU stack can get pushed to a fully software stack anyway, just as you do on RISC systems with no push/pop abstraction. The stack pointer is just a pointer, after all. James ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] InternalsVisibleTo for MoonAtkBridge
Andrés G. Aragoneses wrote: This patch adds InternalsVisibleTo on the 2_1 profile, but using an env var for now until we assure that this is not a security threat. May I commit? Thanks. Patch updated. Index: class/corlib/Makefile === --- class/corlib/Makefile (revision 131333) +++ class/corlib/Makefile (working copy) @@ -25,6 +25,12 @@ corlib_flags = -unsafe -nostdlib LOCAL_MCS_FLAGS = -nowarn:612,618 -d:INSIDE_CORLIB +# this hack will be dropped once we get this working: +# http://www.mono-project.com/Moonlight/SecurityStatus#Assembly_Loading +ifdef MOON_A11Y_INTERNAL_HACK + MCS_FLAGS += -define:MOON_A11Y_INTERNAL_HACK +endif + # System.IO/DirectoryInfoTest.cs needs Mono.Posix TEST_MCS_FLAGS = -debug+ -debug:full -nowarn:168,219,618,672 -unsafe -r:$(topdir)/class/lib/$(PROFILE)/Mono.Posix.dll -define:MONO_DATACONVERTER_STATIC_METHODS Index: class/corlib/Assembly/AssemblyInfo.cs === --- class/corlib/Assembly/AssemblyInfo.cs (revision 131333) +++ class/corlib/Assembly/AssemblyInfo.cs (working copy) @@ -91,4 +91,12 @@ [assembly: InternalsVisibleTo (System.Windows, PublicKey=00240480940006020024525341310004010001008D56C76F9E8649383049F383C44BE0EC204181822A6C31CF5EB7EF486944D032188EA1D3920763712CCB12D75FB77E9811149E6148E5D32FBAAB37611C1878DDC19E20EF135D0CB2CFF2BFEC3D115810C3D9069638FE4BE215DBF795861920E5AB6F7DB2E2CEEF136AC23D5DD2BF031700AEC232F6C6B1C785B4305C123B37AB)] [assembly: InternalsVisibleTo (System.Net, PublicKey=00240480940006020024525341310004010001008D56C76F9E8649383049F383C44BE0EC204181822A6C31CF5EB7EF486944D032188EA1D3920763712CCB12D75FB77E9811149E6148E5D32FBAAB37611C1878DDC19E20EF135D0CB2CFF2BFEC3D115810C3D9069638FE4BE215DBF795861920E5AB6F7DB2E2CEEF136AC23D5DD2BF031700AEC232F6C6B1C785B4305C123B37AB)] [assembly: InternalsVisibleTo (System.Runtime.Serialization, PublicKey=00240480940006020024525341310004010001008D56C76F9E8649383049F383C44BE0EC204181822A6C31CF5EB7EF486944D032188EA1D3920763712CCB12D75FB77E9811149E6148E5D32FBAAB37611C1878DDC19E20EF135D0CB2CFF2BFEC3D115810C3D9069638FE4BE215DBF795861920E5AB6F7DB2E2CEEF136AC23D5DD2BF031700AEC232F6C6B1C785B4305C123B37AB)] + +// this hack will be dropped once we get this working: +// http://www.mono-project.com/Moonlight/SecurityStatus#Assembly_Loading +#if MOON_A11Y_INTERNAL_HACK + [assembly: InternalsVisibleTo (MoonAtkBridge, PublicKey=002404809400060200245253413100040100010071eb6c5575529cbf7244f7a6ea056284f9eae03bcff2cc132c9c490ab309eab0b56bce449df503d9c0a81e520585cdbe70e2fb90434bac04fa6222a80098b7a1a7b3af991a412324bb4325f6b865bb64ebf6d1c206d5732ddfbc70a7389ee53e0c246e3279741ad00503e49842e19bf37b198b402126cb3689c2ea6496a47cb4)] #endif + +#endif + ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Monoco, couroutines and Mono.
Hi James, On Wed, Apr 15, 2009 at 4:17 PM, James Mansion ja...@mansionfamily.plus.com wrote: Tomi Valkeinen wrote: I think you mean OS thread. The coroutines are nothing special, they are similar to any other jitted code that mono produces. Well, except that the core has some knowledge of them now, right? And thus the stack has to be the normal continuous OS stack. Thus? Why? You probably need to pin stack areas, but why can't you malloc (or mmap) some new space and place a stack in it? I think you'll find that Steve Dekorte's libcoro does that. If you are prepared to forgo guard pages and the like (or roll your own handler) then I don't see why the stack pointer absolutely has to be where you expect. And in fact the gubbins that normally gets pushed to the main CPU stack can get pushed to a fully software stack anyway, just as you do on RISC systems with no push/pop abstraction. The stack pointer is just a pointer, after all. James Such stackless[1] design is quite more complicated as doing stack attach/detach isn't trivial. Spaghetti stacks have their issues that this design avoids. The good news is that such change would not require messing with the API, so if this feature gets enough traction and someone from the community decides to sponsor such optimization it would be doable without breaking existing users. [1]stackless in the sense that it doesn't strictly use the C stack ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] InternalsVisibleTo for MoonAtkBridge
Andrés G. Aragoneses wrote: Andrés G. Aragoneses wrote: This patch adds InternalsVisibleTo on the 2_1 profile, but using an env var for now until we assure that this is not a security threat. May I commit? Thanks. Patch updated. As already explained in moon-list, this is needed because glib-sharp and atk-sharp (which will now be merged in one assembly called MoonAtkBridge) access some Marshaling API which is not public anymore in the 2.1 profile. We're also looking at generating spec files for the monolinker to consume, in order for it to not strip the API we need, but this will come later. Andrés -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Use eglib as a default for mono 2.6
Am 15.04.2009 um 16:10 schrieb Paolo Molaro: On 04/15/09 Joachim Ante wrote: Can you guys please switch to eglib as the default across the board, so that this codepath gets properly tested in the real world. We need to move towards using a single mono source base for all our platforms and relying on external dependencies in mono is a lot of pain when we try to build mono. I asked if that could be done for mono 2.4 and it was too late for that, I understand. But could you guys please fix this for mono 2.6. It would really make a big difference for us. I already explained this some time ago, but maybe it was only on irc and at the mono summit. The short answer is: we will never switch to eglib as default. The primary reason is that the eglib symbols would interfere with the real glib symbols used by so many mono apps. Why not take the same route as GNU libiconv? The eglib headers could #define GLib symbols to have a mono_ prefix, distinguishing them from any real GLib symbols that might get linked in somewhere. Mono's runtime code would then not need to be touched and one could still choose to link against original GLib. Andreas What needs to happen is the following: 1) take a data structure implemented in eglib and copy it to mono/ utils, renaming the file and the symbols to have mono_ instead of g_ at the start. 2) replace all the uses of that glib data structure in the mono code with the new equivalent mono_ version 3) repeat the above for all the data structures, functions and GLib types used by mono After that is done, remove eglib from svn, remove the glib dependency from the mono build, change the libmono version number since the ABI and API breaks, fix all the bugs that showed up because of the changes, make a new release. The library version change will happen together with the other API breaks we have planned (which depend on the new GC and a few other minor changes in the runtime), but that stuff is not required for your needs. So far nobody has volunteered for the tasks 1-3. lupus -- - lu...@debian.org debian/rules lu...@ximian.com Monkeys do it better ___ 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] Problem with PPC/PPC64 and disabling builds against the static libs
Toshio Kuratomi a.badger at gmail.com writes: The package I've just built for Fedora does this (links /usr/bin/mono against the static libmono.a and then removes the static libraries prior to finishing the package). The concern I have with this strategy long-term is that programs wanting to embed the mono runtime will be linking against the dynamic libmono.so. If this is causing issues for /usr/bin/mono and we don't know what the trigger is, isn't this a potential problem for them as well? A little poking looks like I was right about this problem :-( On ppc, with the statically compiled mono-2.4 final, trying to use the embedding samples yields this: cd mono-2.4/samples/embed gcc -o teste teste.c `pkg-config --cflags --libs mono` -lm mcs test.cs ./teste test.exe Segmentation fault And: cd mono-2.4/samples/embed gcc -Wall -o test-invoke test-invoke.c `pkg-config --cflags --libs mono` -lm mcs invoke.cs ./test-invoke invoke.exe Segmentation fault -Toshio ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Use eglib as a default for mono 2.6
On Wed, 2009-04-15 at 22:49 +0200, Andreas Färber wrote: [...] Why not take the same route as GNU libiconv? The eglib headers could #define GLib symbols to have a mono_ prefix, distinguishing them from any real GLib symbols that might get linked in somewhere. Mono's runtime code would then not need to be touched and one could still choose to link against original GLib. Are you volunteering? :-) -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Monoco, couroutines and Mono.
Hi, On Wed, 15 Apr 2009, James Mansion wrote: Tomi Valkeinen wrote: I think you mean OS thread. The coroutines are nothing special, they are similar to any other jitted code that mono produces. Well, except that the core has some knowledge of them now, right? Well, some, of course. But a continuation is just a piece of stack, stored somewhere. The jitted code itself is the same as normally. And thus the stack has to be the normal continuous OS stack. Thus? Why? You probably need to pin stack areas, but why can't you malloc (or mmap) some new space and place a stack in it? I think you'll find that Steve Dekorte's libcoro does that. If you are prepared to forgo guard pages and the like (or roll your own handler) then I don't see why the stack pointer absolutely has to be where you expect. And in fact the gubbins that normally gets pushed to the main CPU stack can get pushed to a fully software stack anyway, just as you do on RISC systems with no push/pop abstraction. The stack pointer is just a pointer, after all. The stack must be able to grow, otherwise we may run out of stack. If we want to manage a proper stack for each continuation, we need to allocate it in page sized chunks, and we need the guard pages. This would increase the required memory needed for each continuation quite a bit. Also, the stack contains pointers to variables in the stack, so the stack has to be in the same memory location. Tomi ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
