Re: [Mono-dev] libtool build error message
Found it out now (for future reference): I had installed a different version of libtool using fink. I'm not sure of what exactly went wrong here - I think it was using a non- matching libtool binary and acinclude file. Uninstalling libtool in fink solved the problem. jonas On Aug 8, 2009, at 11:18 PM, Christian Hergert wrote: Hi Jonas, I ran into something similar recently. Can you try running autoreconf -fiv in the checkout to rebuild the libtool files and such. (then re-configure/make as normal). -- Christian On Aug 8, 2009, at 5:07 AM, jonas echterhoff wrote: just fine - but the svn build always fails on a clean checkout with this error: ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] libtool build error message
Hey everyone, my OS X setup suddenly stopped being able to build mono from svn. The mono 2.4 tarball compiles just fine - but the svn build always fails on a clean checkout with this error: checking if dolt supports this host... yes, replacing libtool libtool: ltconfig version `' does not match ltmain.sh version `1.3.5' It shows the error in configuration, but continues to run - but then when running make, it will show the same error, and fail to build. Has anyone else ever seen this? Did I break anything in my setup? jonas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Debugging Memory mono images
So, I got the debugger working so far that we can debug Unity on the Mac. However, there's one issue I'm wondering about: In Unity, we load mono images from memory, and not from a file on disk. So, we use mono_image_open_from_data_full(), instead of mono_image_open_full(). This gives me an error in the debugger, because it cannot find the symbol files: Cannot load symbol file `data-0x1a67' We do use mono_debug_open_image_from_memory() to associate the symbol data with the image, but either that is ignored by the debugger, or it is too late, because it's after the mono_image_open_from_data_full() call. Any idea how this is best fixed? jonas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Debugger Unit tests
How do I run the unit test suite for the debugger? Thanks, jonas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] monodev and debugging on mac os x ( linux as well)
I posted a patch for the mono debugger (command line mdb) for Mac OS X to this list. If you're feeling adventurous, you can build it and try it out. jonas On May 15, 2009, at 10:24 AM, daniel paiva wrote: Hi, Thanks for answers. G:D 2009/5/15 Michael Hutchinson m.j.hutchin...@gmail.com: On Thu, May 14, 2009 at 9:05 AM, Félix.RVA f.ruiz-valdepe...@premavals.com wrote: You can use the integrated Debugger on Monodevelop only on the 2.0 version or higher. I don't know how it works on the Mac version but on Linux distributions you must install the monodevelop-debugger packages (gdb and mdb) ... then the debugger options will be available on the monodevelop IDE. The Mono debugger only works on Linux x86/x86_64 at this time. There are porting efforts underway for Windows and Mac, but no ETA yet. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from your system. ___ 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] Building Mono Develop on OS X
I want to try to get the mono debugger integration work with Mono- Develop on Mac OS X. Now I'm stuck trying to build mono-develop from svn, because of all the involved dependencies. What is the easiest way to get bootstrapped with this? Is there a package manager which can install the requirements for me? Or something which gives me the whole package? When I install the mono framework, that has most or all of what is needed, any way to compile against that? jonas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Building Mono Develop on OS X
When I just try ./configure --profile=mac after installing the framework, I get: ./configure: line 2697: syntax error near unexpected token `UNMANAGED_DEPENDENCIES_MONO,mono' ./configure: line 2697: `PKG_CHECK_MODULES(UNMANAGED_DEPENDENCIES_MONO,mono = $MONO_REQUIRED_VERSION, has_mono=true, has_mono=false)' When I use --prefix to specifiy my mono installation I build from svn (which I ultimately want, since that's the only place where I have my debugger code), I get further then that, but then I'm missing all the requirements (need to build mono-addins, which requires GTK#, which requires pango, etc...) jonas On May 15, 2009, at 8:17 PM, Miguel de Icaza wrote: Hello Jonas, I want to try to get the mono debugger integration work with Mono- Develop on Mac OS X. Now I'm stuck trying to build mono-develop from svn, because of all the involved dependencies. What is the easiest way to get bootstrapped with this? Is there a package manager which can install the requirements for me? Or something which gives me the whole package? When I install the mono framework, that has most or all of what is needed, any way to compile against that? That should have everything you need. I know that this is all I had myself. Could you paste the error messages that you are getting? Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono Debugger and Mono 2.4
Following up on my own post here, I have managed to make mdb work with Unity (to some degree). It was mostly as easy as Miguel said, just instruct Unity to use mono the same was as if mono --inside_mdb had been called. Reading the MONO_DEBUGGER__debugger_info struct still is a problem, though. I was wrong in my last post that mdb won't try to read it for native applications. Rather, the problem is, that since we are linking against mono dynamically, the debugger will first interrupt when loading Unity, before the linker has resolved the external dynamic symbols, thus it won't get the correct address for the struct. I have worked around this for now, by making the debugger ignore the first stop, which works, but breaks compatibility with everything but Unity - so I really need some better fix. Does anybody know the OS X linker very well? I tried setting the DYLD_BIND_AT_LAUNCH environment variable, but that still seems to link the symbol too late. If nobody knows a more elegant solution, I'd need to change the debugger to try again and read the symbol table again, if the symbol is unresolved the first time, but if it can be fixed by some different link settings, i'd prefer that. jonas On May 5, 2009, at 5:37 PM, jonas echterhoff wrote: Yes. But in order to make it work, as far as i can tell, I also need to change the mono debugger itself. Right now, when I load a native application into the debugger, it won't try to find the debugger_info global structure, which is used to communicate with mono. My question is mostly, since there is some support for native applications in mdb at this point (well, I can start an application in the debugger, and interrupt and resume execution), if there is already some workaround for this, or a plan on how to implement it. I obviously don't want to do special case code for unity which will be a pain to drag along in the future. jonas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Attaching mdb?
Does anyone know the status of attaching to programs in mdb at the moment? According to http://www.mono-project.com/Debugger: Can attach to existing Mono processes [DONE] Well, that doesn't seem to be the case. By default, attaching is not allowed at all, when I enable the Martin_Boston_07102008 in the config file in mono 2.4 on linux, i can attach to a running mono process, but I wasn't able to do any source level debugging. I guess this is because the debugger didn't get all the information it needs from mono on loading. What are the plans for this? For us, it would be great to have a workflow where users would just have an Attach/Detach debugger button, so they can start debugging at any time, without restarting Unity. Also, it would solve the little problem I described in my previous post. jonas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono Debugger and Mono 2.4
Since we will be using Mono 2.4 in future Unity releases, that means I need to backport my debugger changes to 2.4. I just want to make sure that there are no stepping stones when doing that - are there any major changes done to the debugger since then I should be aware of? Also, I'm still looking for any suggestions on how to get the mono debugger to work with a native application invoking mono from a dll. What's the status, should that work at the moment? If not, what needs to be done to make it work? jonas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono Debugger and Mono 2.4
libbfd is an abstraction layer for the different executable formats (as you probably know). It is needed to find symbol information when debugging non-managed code, and to find the debugger hooks in the mono runtime. And probably for reading coredumps and many other things as well. Only minimal changes were needed to make it work on Mac OS X (since it supports Mach-O out of the box). I presume the situation should be similar on windows as well. jonas On May 4, 2009, at 12:04 PM, Friedrich Dominicus wrote: I've some extra questiosn about the Debugger also. Is it correct that mdb can not be used to debug itself? Another question is what role play the libbfd library in it? Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus ___ 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] Debugging native applications
Now that I have the mono debugger on OS X in a state, where we can start trying to use it for something, I'm wondering how we would go along with integrating it with Unity. Apparently there should be some support in mdb for debugging native applications. So far all I've been able to do is run a native application with the debugger attached, without setting any breakpoints or anything. So, I'm wondering, what is the status of this right now? And then, what changes would be needed to fully debug mono code executed from native applications using mdb? I guess that the mono dll runtime would have to be modified to add the debugger hooks normally enabled using the --inside-mdb option to the mono executable. Or is that already possible? What else needs to be done? jonas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] OS X debugger
Here is an updated version of my mono debugger patch. This is much more functional then the previously submitted patch, now working properly with multi-threaded apps. Getting the threading to work as expected was a bit difficult, because the way ptrace works (or doesn't work) on OS X is that it will always trace a complete process, stopping all threads when one of them signals, and resuming all of them when one resumes. The other issue is that ptrace won't send any events when new threads are created or old ones are terminated. I have tried to mask these differences as good as possible, so the changes to the non-darwin specific files are minimal. The wait function will detect which thread has signalled, and return a reference to it. Since Mach doesn't seem to have global pids for threads (light-weight-processes), I construct that reference (referred to as pid in the C# code) from the actual process pid, and an index for the thread in the high bits. Since new threads aren't automatically detected, some changes to ThreadManager.cs were necessary to look for new threads, and to check if any threads have exited. I added a function to query for functionality from the backend to enable this changes - so the linux version should still work from the same source. It is necessary to code sign mono for this to work. See my previous post for information Some known issues (probably many more unknown ones): -The debugger will not follow forks on OS X. -For some reason, when jiting some code which has breakpoints in it, the debugger gives an error message like: Can't insert breakpoint 3 at 0x004de0bf: Already have breakpoint 3 at address 0x004de0bf. This is because the MONO_DEBUGGER_EVENT_JIT_BREAKPOINT gets sent twice, once at mono-debug-debugger.c:209 and once at mono-debug- debugger.c:222. If Martin or anyone has an idea why that is, let me know. This doesn't cause any troubles, I just want to figure out what is wrong and causing the error message. -Sometimes interrupting using ^C while a thread is in Thread.Sleep, it will not wake up again after resuming. It seems that the thread is executing some code (registers and frame change each time I interrupt), but it will never leave the Sleep function. Some things I didn't test (because I didn't find out how they are supposed to work): -Watchpoints -Debugging Native applications More information on these would be appreciated. jonas Diff files for mono and debugger repositories: http://files.unity3d.com/jonas/mono.diff http://files.unity3d.com/jonas/debugger.diff ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono Debugger - Unity
This list. I'm working on the mac port of mdb. I'm planning to submit a patch later this day, which should be mostly usable in theory (I'm sure testing would prove me different). That said, it's still a long way before this can be used with Unity. jonas On Apr 28, 2009, at 12:10 AM, Timothy Graupmann wrote: Mono Development, What email distribution list are you using mainly to communicate about the Mono debugger on Windows/Mac? Is there a specific mailing list that you are using to talk about the Mono Debugger being used with Unity? Thanks, ~Tim ___ 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] [PATCH] mono debugger for Mac OS X
On Apr 21, 2009, at 10:06 PM, Miguel de Icaza wrote: Hello Jonas, Some feedback on the patches mono.diff: * In general, they are missing ChangeLog entries that document what the changes are. In particular it would be useful to document the rationale behind the changes in the signal definitions in the libgc directory. * The coding style should adhere to the Mono coding style, for example isInited should become is_initialized, for more info: http://mono-project.com/Coding_Guidelines It is not clear why that change was needed in the first place, so a ChangeLog entry here would help. Since we have not ran into this in the past, I suspect that this might be hiding a problem elsewhere. * The change to mono/mini/Makefile.am probably should be a platform_ldflags and be set in configure.in instead to avoid yet another if macro there I hope to get multi-thread support to work properly this week - then I will submit a new patch. I will take care to add proper ChangeLog entries, and address these issues. * The tests/tests-config change, why is that necessary? The proper change would be to use os specifiers there see the mono-config(5) man page for details. It is not. The file gets automatically changed/generated on make, and thus was accidentally added to the .diff. Does it have to be in svn at all? debugger.diff: * The reason why the configure.in test for PLATFORM_X86_DARWIN does not work is that this is an autoconf macro that is only exposed to the automake world (the Makefile.am) and it is not available during configure time. Inside configure.ac or configure.in you must use the shell- level variables that you defined (the ones that actually detected PLATFORM_x86_DARWIN). you mean this? +#not sure why, but I cannot get this test to pass on OS X. +if test x$PLATFORM_X86_DARWIN = xno ; then But the test for PLATFORM_X86_DARWIN actually works. What does not work is the checking code in between the if, which is why I had to add that test. jonas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono-Debugger: Multiple threads and SingleSteppingEngines?
I got debugging of multi-threaded applications to work in OS X, as in supporting it on the backend. But what I don't quite get yet is how multi-threaded applications should be handled and represented inside the debugger. In ThreadManager.cs, there is a comment: // For each application we're debugging, there is just one SingleSteppingEngine, // no matter how many threads the application has. The engine is using one single // event loop which is processing commands from the user and events from all of // the application's threads. Somehow, it seems to me that this is not really the case. In ProcessServant.ThreadCreated (which is called when a new thread is created by the application): SingleSteppingEngine new_thread = new SingleSteppingEngine ( manager, this, new_inferior, pid); Seems to contradict that. Looking at the code, I assume the above comment is wrong. It appears that the debugger will create one SingleSteppingEngine plus Inferior for each thread. Am I right? jonas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] mono debugger for Mac OS X
I should add that this contribution is being done under the MIT X11 license. jonas On Apr 16, 2009, at 5:53 PM, jonas echterhoff wrote: I attached two diff files (one for the debugger module, one for the mono module itself), which implement the mono debugger for Mac OS X. I have never submitted a patch for mono before, so if there's anything else I need to do, let me know. This lets you use mdb to debug mono programs on Mac OS X, as you would in Linux. It is probably very unstable. Some known issues: -Currently, you can only debug the main thread of an executable. -It will not always gracefully exit after the debugged executable terminates -Watchpoints don't work yet. Mac OS X Leopard (which is required to run this) has a security mechanism to determine which processes are allowed to access other processes memory/register states. This works by signing the executable with a trusted certificate. So, in order to use this, you will have to create a certificate for code signing, as described here: http://developer.apple.com/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html#/ /apple_ref/doc/uid/TP40005929-CH4-SW1 Choose Get Info for the newly created certificate in Keychain Access.app, and under Trust, set Code Signing to Always Trust. Now, sign the mono executable you built with the patch using: codesign -v -s NAME_OF_CERTIFICATE $YOUR_MONO_INSTALL_DIRECTORY/ bin/mono Let me know if there are any questions, jonas debugger .diffmono.diff___ 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] 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] Porting Mono Debugger to OSX
On Apr 14, 2009, at 3:02 PM, Martin Baulig wrote: Still, I don't get mdb to properly run an executable yet. I believe the problem may be that in OS X, i don't get any events from ptrace, which seem to be used to initialize the debugger (like PTRACE_EVENT_CLONE, etc..). When ptrace stops, it always just gives a normal SIGTRAP signal. PTRACE_EVENT_CLONE etc. are extended notifications which need to be explicitly enabled via ptrace (PTRACE_SETOPTIONS) - but they may not be supported in all ptrace implementations. This is done in server_ptrace_initialize_process() in x86-linux-ptrace.c. But even without these extended notifications, you should still be able to get the normal ptrace events. right. These extended notifications are not supported on OS X. I got it to start up now without crashing, I will just have to find a way to detect new threads (currently starting a new thread will not stop execution), and to follow forks. That can wait for now. 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? Thanks for any help, jonas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] ptrace events in mono debugger
(Cross-posting this to mono-devel as suggested by Joachim.) Begin forwarded message: From: jonas echterhoff jo...@unity3d.com Date: April 10, 2009 1:38:29 PM GMT+02:00 To: mar...@ximian.com Cc: Joachim Ante j...@unity3d.com Subject: Porting Mono Debugger to OSX Hey Martin, I'm currently working on porting the mono debugger to Mac OS X. The biggest issue here is that ptrace is only partially implemented, and a lot of it's functionality needs to be replaced by mach-o code. At this point, a lot of that actually works, reading/writing memory, reading registers, reading the executable format, etc. Still, I don't get mdb to properly run an executable yet. I believe the problem may be that in OS X, i don't get any events from ptrace, which seem to be used to initialize the debugger (like PTRACE_EVENT_CLONE, etc..). When ptrace stops, it always just gives a normal SIGTRAP signal. Now, I don't have a Linux machine to see how this code should actually work, so I'm wondering, when I start an executable in mdb, which events needs to be sent to the debugger to properly initialize it? Will ptrace stop multiple times on Linux before starting execution (once when execd, once when the first thread is created, etc)? On OS X, ptrace won't stop on thread creation. Regards, jonas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Porting Mono debugger to Mac OS X
Hey everyone, I'm working for Unity Technologies, and I am currently starting to port the mono debugger to Mac OS X, as we want to offer a proper debugging solution for users of the Unity game engine. So far things are looking alright, I've managed to make the debugger compile by adding some stub functions for the functionality which is different in OS X. So far, I see the following tasks which need to be done to get this to work: -Make mono debugger read Mach-O binary format (shouldn't be too difficult, since bfd can read Mach-O). -Replace missing ptrace functionality with Mach-O calls (ptrace exists on OS X, but is only partially implemented). -Possibly reimplement libthread-db functionality somehow, as OS X doesn't have libthread-db (this i'm not quite sure about at the moment. Where and how is this used?) At the moment, I'm coming along fine, currently i'm working on getting the Mach-O binary support to work, so this email is mostly just about introducing the project and saying hi. I'm sure I'll have a lot of specific questions further down the road. Fell free to give me generic advice on this task, if there's anything I should be aware of, though. Cheers, jonas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
