Re: [Mono-dev] Embedded API: .ctor method signature query [mono]

[Jonathan Mitchell]

HI Robert

> 
> You may want to file a bug, though.

Bug is in at:
https://bugzilla.xamarin.com/show_bug.cgi?id=39343

After logging the bug I managed to fix it myself on my current target 4.0.0. 
https://github.com/mono/mono/pull/2724

4.2.0 will need this too.

Jonathan
> 
> Robert
> 
> 
> On 03.03.2016 19:28, Jonathan Mitchell wrote:
>> HI Robert
>> 
>> Thanks for that.
>> I think you are right.
>> I call hundreds of methods that take Obj`1 arguments with out issue but I 
>> see that I have had to construct a number of helper methods to deal with 
>> cases of Obj`2<T, K> which failed signature resolution.
>> 
>> I presume that  managed code execution doesn’t involve calls to 
>> mono_method_desc_new() - are thunks used instead?
>> One of the difficulties, I find, of working with the embedded API is trying 
>> to visualise just how a particular managed code statement is implemented 
>> within the runtime.
>> 
>> I was hoping to be able to call the constructor from C with a pointer to a 
>> static (MonoString *)fund(MonoString *).
>> Not sure if that would even fly.
>> 
>> As a work around I will use an internal call.
>> 
>> Shall I log this as a bug and reference this thread?
>> 
>> Thanks a lot for replying.
>> 
>> Jonathan
>> 
>>> On 3 Mar 2016, at 18:02, Robert Jordan <robe...@gmx.net> wrote:
>>> 
>>> On 03.03.2016 14:36, Jonathan Mitchell wrote:
>>>> HI
>>>> 
>>>> I want to call the following constructor via the embedded API:
>>>> 
>>>> public CloudClient(Func<string, string> filePathCallback)
>>>> 
>>>> All my other embedded method and constructor calls work okay but there is 
>>>> an issue with this one - it is the only place I use a System.Func.
>>>> The API reports that a method cannot be found for signature 
>>>> .ctor(System.Func`2<string, string>)
>>>> When I dump out the class method names I see .ctor(System.Func`2<string, 
>>>> string>) listed.
>>>> 
>>>> Any ideas on this one?
>>> 
>>> It looks like a bug in mono_method_desc_new ():
>>> 
>>> https://github.com/mono/mono/blob/master/mono/metadata/debug-helpers.c#L378
>>> 
>>> The function is treating
>>> 
>>> .ctor(System.Func`2<string, string>)
>>> 
>>> like a method with 2 arguments:
>>> 
>>> arg0 = System.Func`2>> arg1 = string>
>>> 
>>> This is obviously wrong :)
>>> 
>>> The function is then storing the (wrong) argument count
>>> for optimization purposes, and the comparison of methods
>>> is starting to fail:
>>> 
>>> https://github.com/mono/mono/blob/master/mono/metadata/debug-helpers.c#L447
>>> 
>>> Robert
>>> 
>>> 
> 
> 
> ___
> 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] Embedded API: delegate type building

[Jonathan Mitchell]

Hi

At present I use an InternalCalls for my callbacks and conditional compilation 
(see end) in our cross platform code
In this we assign  a Func directly to an extern static string 
FilePathCallback(string EmployerName);

 In future I would like to support calling methods such as

public CloudClient(Func filePathCallback) 

using the Embedded API and cut out the extra plumbing need for InternalCalls.

I have a wooly feel for how I should approach this!
When generating generic types I use a managed helper method.

So I could envisage creating a System.Delegate instance of System.Func.
Then I could set the Target and Method properties - however since I am calling 
back into C there won’t be a Target class.
However System.Delegate is abstract so I would need to sort that out too! - 
presumably this needs to be done dynamically at runtime.

I am aware of the existence of Delegate.CreateDelegate() put that only seems to 
work for instance delegates.

Any insight would be helpful.

Thanks

Jonathan

end
===
public class CloudClient
{
#if TARGET_OSX
[MethodImplAttribute(MethodImplOptions.InternalCall)]
extern static string FilePathCallback(string EmployerName);
#endif
public CloudClient(Func filePathCallback) {

_filePathCallback = filePathCallback;

#if TARGET_OSX
if (_filePathCallback == null) {
_filePathCallback = FilePathCallback;
}
#endif
}

}





___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Embedded API: .ctor method signature query [mono]

[Jonathan Mitchell]

HI Robert

Thanks for that.
I think you are right.
I call hundreds of methods that take Obj`1 arguments with out issue but I 
see that I have had to construct a number of helper methods to deal with cases 
of Obj`2<T, K> which failed signature resolution.

I presume that  managed code execution doesn’t involve calls to 
mono_method_desc_new() - are thunks used instead?
One of the difficulties, I find, of working with the embedded API is trying to 
visualise just how a particular managed code statement is implemented within 
the runtime.

I was hoping to be able to call the constructor from C with a pointer to a 
static (MonoString *)fund(MonoString *).
Not sure if that would even fly.

As a work around I will use an internal call.

Shall I log this as a bug and reference this thread?

Thanks a lot for replying.

Jonathan

> On 3 Mar 2016, at 18:02, Robert Jordan <robe...@gmx.net> wrote:
> 
> On 03.03.2016 14:36, Jonathan Mitchell wrote:
>> HI
>> 
>> I want to call the following constructor via the embedded API:
>> 
>> public CloudClient(Func<string, string> filePathCallback)
>> 
>> All my other embedded method and constructor calls work okay but there is an 
>> issue with this one - it is the only place I use a System.Func.
>> The API reports that a method cannot be found for signature 
>> .ctor(System.Func`2<string, string>)
>> When I dump out the class method names I see .ctor(System.Func`2<string, 
>> string>) listed.
>> 
>> Any ideas on this one?
> 
> It looks like a bug in mono_method_desc_new ():
> 
> https://github.com/mono/mono/blob/master/mono/metadata/debug-helpers.c#L378
> 
> The function is treating
> 
>   .ctor(System.Func`2<string, string>)
> 
> like a method with 2 arguments:
> 
> arg0 = System.Func`2 arg1 = string>
> 
> This is obviously wrong :)
> 
> The function is then storing the (wrong) argument count
> for optimization purposes, and the comparison of methods
> is starting to fail:
> 
> https://github.com/mono/mono/blob/master/mono/metadata/debug-helpers.c#L447
> 
> Robert
> 
> 
> 

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Embedded API: .ctor method signature query

[Jonathan Mitchell]

HI

I want to call the following constructor via the embedded API:

public CloudClient(Func filePathCallback)
 
All my other embedded method and constructor calls work okay but there is an 
issue with this one - it is the only place I use a System.Func.
The API reports that a method cannot be found for signature 
.ctor(System.Func`2)
When I dump out the class method names I see .ctor(System.Func`2) listed.

Any ideas on this one?

Thanks a lot

Jonathan
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Embedded API : Error initialising the configuration system

[Jonathan Mitchell]

Hi

On Mono 4.0.4.4

My app uses the embedded API to run managed code in a Cocoa OS X environment.
Just recently, having updated some of my managed code, I have been getting 
errors from the managed configuration system.

Error initialising the configuration system
System.Configuration.ConfigurationErrorsException.

I use mono_jit_exec() to run an exe assembly with a static Main().

Prior to this I call mono_domain_set_config() with the path to the exe assembly 
folder and the path to the exe assemble config.

Have I missed something?

Thanks

Jonathan
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Building 4.2 on OS X

[Jonathan Mitchell]

I can build Mono 4.0 64bit on OS X 10.10 without issue.
The 4.2 build dies:

./../../external/referencesource/System.Data.SqlXml/System/Xml/Xsl/Xslt/Scripts.cs(117,48):
 error CS0117: System.CodeDom.Compiler.CodeDomProvider' does not contain a 
definition forGetCompilerInfo'
./../../class/lib/basic/bare/System.dll (Location of the symbol related to 
previous error)

My installed Mono is 4.0.
My build script says:

./autogen.sh --prefix=$PREFIX --disable-nls
make
make install

The error call site is here:
=
System.Xml.Xsl.Xslt.ScriptClass
=
   public ScriptClass GetScriptClass(string ns, string language, 
IErrorHelper errorHelper) {
#if CONFIGURATION_DEP
   CompilerInfo compilerInfo;
   try {
   compilerInfo = CodeDomProvider.GetCompilerInfo(language); // 
error CS0117: System.CodeDom.Compiler.CodeDomProvider' does not contain a 
definition forGetCompilerInfo'
   Debug.Assert(compilerInfo != null);
   }
   catch (ConfigurationException) {
   // There is no CodeDom provider defined for this language
   
errorHelper.ReportError(/*[XT_010]*/Res.Xslt_ScriptInvalidLanguage, language);
   return null;
   }

   foreach (ScriptClass scriptClass in scriptClasses) {
   if (ns == scriptClass.ns) {
   // Use object comparison because CompilerInfo.Equals may 
throw
   if (compilerInfo != scriptClass.compilerInfo) {
   
errorHelper.ReportError(/*[XT_011]*/Res.Xslt_ScriptMixedLanguages, ns);
   return null;
   }
   return scriptClass;
   }
   }

   ScriptClass newScriptClass = new ScriptClass(ns, compilerInfo);
   newScriptClass.typeDecl.TypeAttributes = TypeAttributes.Public;
   scriptClasses.Add(newScriptClass);
   return newScriptClass;
#else
   return null;
#endif
   }

Thanks

J












___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building 4.2 on OS X

[Jonathan Mitchell]

> On 10 Nov 2015, at 10:01, Numpsy  wrote:
> 
> I've built the 4.2.1.91 tarball successfully on 64bit OSX, though that was
> using a downloaded 32bit 4.2 build as the compiler.
> 
Thanks for that.
I tried building the latest 4.2 GitHub branch using the current 32 bit 4.2 
download binary but the issue remains.
I will hook up a clean 10.10 VM and try a build on it.

> fwiw, when I tried building the latest Git master recently I got some
> failures due to missing definitions for the new TLS stuff, and it worked
> after cleaning everything out and adding $PREFIX/bin to the path (must have
> been trying to build against the old assemblies i guess).
> 
> 
> 
> --
> View this message in context: 
> http://mono.1490590.n4.nabble.com/Building-4-2-on-OS-X-tp4666924p4666925.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-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] boehm and pin to sgen and moveable

[Jonathan Mitchell]

Robert

> On 4 Oct 2015, at 19:02, Robert Jordan <robe...@gmx.net> wrote:
> 
> Hey Jonathan,
> 
> On 03.10.2015 16:25, Jonathan Mitchell wrote:
>> 
>> 
>> Under the Boehm collector objects seem to stay pinned as requested.
>> Under SGEN they don’t i.e.: the exception in the second method below raises 
>> i.e.:  self.monoObjectTrace != (NSUInteger)monoObject)
>> 
>> What am I doing wrong?
> 
> It depends on how your methods are actually used.
> 
> In setMonoObject, there is a time frame between
> 
> mono_gchandle_free ()
> mono_gchandle_new ()
> 
> where the GC might regain control and move the object.

Thanks for the reply.
I took another look at this and excluded the possibility of the GC moving the 
object in a time frame (setMonoObject is publicly private and is only set 
internally within the class once.)
The issue does not appear when using libmonoboehm, only libmonosgen.
I must be screwing things up somewhere. The issue is 100% repeatable.

I would like to use sgen as it is getting all the TLC now.

I build my own 64 bit runtime for OS X - current up to date with 4.0.4.4.
I note that the existing 32 bit framework packages for OS X still link to 
libmonoboehm by default (thats where the framework bundle Mono symlink points 
to)
I will try adding moveable memory support to my bridge code as well and see how 
that goes.

With regard to moveable memory:
I use mono_object_hash() to key MonoObject * instances as it stays constant 
through the MonoObject lifetime, even for moveable objects.
The mono_object_hash() key is used to look up a possible NSObject match, 
testing on -MonoObject equality for each item in the bucket to establish 
uniqueness.

To test this out I plan to generate a bunch of objects (occupying > than the 
SGEN nursery area allocation of 4MB).
Then collect with 
mono_gc_collect (mono_gc_max_generation ());
and validate that movement has occurred na is correctly handled.

Does that sound sensible or daft?

J


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] boehm and pin to sgen and moveable

[Jonathan Mitchell]

In my ObjC->Mono bridge I have been using the Boehm collector and pinned memory 
(as an expedient).
I now want to move to SGEN and moveable memory.
As a first step I have switched to SGEN and left pinning enabled.

My ObjC code wraps a MonoObject * in an NSObject.
When the MonoObject is set it is pinned.
A simple monoObjectTrace property watches to see if the MonoObject moves.

Under the Boehm collector objects seem to stay pinned as requested.
Under SGEN they don’t i.e.: the exception in the second method below raises 
i.e.:  self.monoObjectTrace != (NSUInteger)monoObject) 

What am I doing wrong?

I do want to migrate to moveable memory support ASAP but a step wise approach 
seems best.

#define DB_TRACE_MONO_OBJECT_ADDRESS

- (void)setMonoObject:(MonoObject *)monoObject
{
if (_mono_gchandle) {
NSLog(@"calling mono_gchandle_free!");
mono_gchandle_free(_mono_gchandle);
_mono_gchandle = 0;
}

// we don't want to persist the monoObject in an ivar or on the heap in 
general as it would
// require always pinning the pointed to MonoObject
if (monoObject) {
_mono_gchandle = mono_gchandle_new(monoObject, 
self.monoEnvironment.pinGCHandles);
}

#ifdef DB_TRACE_MONO_OBJECT_ADDRESS
self.monoObjectTrace = (NSUInteger)monoObject;
#endif

}

- (MonoObject *)monoObject
{
// This pointer should be valid while it is visible on the unmanaged stack.
// Dont save it into the heap as it may become invalid if the MonoObject is 
not pinned
// and the managed instance gets moved in memory.
MonoObject *monoObject = mono_gchandle_get_target(_mono_gchandle);

#ifdef DB_TRACE_MONO_OBJECT_ADDRESS
if (self.monoObjectTrace != (NSUInteger)monoObject) {
[NSException raise:@"Managed object has moved" format:@"Support for 
moved managed objects is pending."];
}
#endif

return monoObject;
}

Jonathan










___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Old version of Entity Framework bundled with Mono

[Jonathan Mitchell]

 On 8 Aug 2015, at 05:52, Daniel Lo Nigro li...@dan.cx wrote:
 
 I recently spend a while debugging an issue I was having with Entity 
 Framework, only to find that it was happening because Mono ships with a beta 
 version in its GAC. Would it be possible to either update this to the latest 
 release build, or stop shipping with it and instead let people use their own 
 version from NuGet? There's some bugs in the bundled beta that were resolved 
 in the final release, and it's lacking some of the classes (for example, 
 DbConfiguration is missing). Shipping an older version in the GAC is 
 problematic as a GAC'd version of an assembly is always preferred over a 
 local copy, so I needed to completely delete it from the GAC to get my site 
 to work properly.

I use the current NuGet version of EF and just deleted the old version from the 
GAC.












___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Compiling Mono with debug symbols to diagnose an issue with embedded Mono 4.0.2.5

[Jonathan Mitchell]

 On 5 Aug 2015, at 18:19, Alexander Köplinger alex.koeplin...@outlook.com 
 wrote:
 
 You can build the MDK with 
 https://github.com/mono/bockbuild#the-mono-mac-distribution, but I'm not sure 
 if that includes debug symbols (I think it does).
 
Nice to see that bockbuild now has some usage notes in the readme.
It says:

$ git clone g...@github.com:mono/bockbuild bockbuild
$ cd bockbuild/profiles/mono-mac-release
$ MONO_VERSION=4.9.9 ./mono-mac-release.py --build --arch darwin-32

Not sure if that generates a symbolicated build.


 -- Alex
 
 From: jonat...@mugginsoft.com
 Date: Wed, 5 Aug 2015 18:06:37 +0100
 To: Mono-devel-list@lists.ximian.com
 Subject: Re: [Mono-dev] Compiling Mono with debug symbols to diagnose an 
 issue with embedded Mono 4.0.2.5
 
 
 On 5 Aug 2015, at 02:12, jean-michel.perr...@csiro.au wrote:
 
 I am trying to debug C code, mostly to step through the mono runtime itself.
 I too would like to debug the Mono runtime itself and so would really, 
 really, really like to able to build an MDK with debug symbols and source 
 code references.
 
 Why do I need to debug the runtime?
 I have written an Obj-C  C# bridge utilising the runtime and in some 
 situations I cannot figure out what the correct embedded API function 
 signatures are for more complex generic managed methods. Being able to debug 
 the runtime would give me some insight into what is going on in the method 
 signature search process.
 
 That said, I would not at all refuse a howto guide for mixed mode (C and 
 C#) debugging on Linux (not possible so far as I know). I may try to give a 
 try on Windows with Visual Studio, but as a fallback option as this issue 
 may not be reproducible on it anyway.
 
 Here is my take on debugging Mono based on working on OS X.
 
 C
 ==
 
 On the Obj-C side (Obj-C is a strict superset of C) I should be able to step 
 into the Mono runtime code via the Xcode side if my Mono runtime build 
 supported debug symbols and their source code references. I reckon that most 
 C IDEs should be fit to do the same.
 
 
 C#
 ==
 
 I don’t know of a way to seamlessly debug both C and C# via the same IDE on 
 OS X (perhaps VS can so this on windows).
 To debug the managed code in my OS X app I do roughly the following (more 
 detail follows in the notes below).
 
 1. Configure the OS X app embedded Mono code to use the Mono soft debugger 
 (this is a remote capable software debugger that runs over TCP-IP see 
 http://www.mono-project.com/docs/advanced/runtime/docs/soft-debugger/).
 2. Run my OS X outside of my Xcode IDE. If I don’t do this then the signals 
 generated by the debugee tend to get caught by the IDE debugger rather than 
 the Mono soft debugger.
 3. Fire up Xamarin Studio (XS) on a Windows machine (in my case a Windows VM 
 on the same physical machine but a networked base PC should work just fine 
 too).
 4. In XS connect to the remote debugger, set breakpoints etc.
 5. Exercise the OS X app and trigger breakpoints in XS.
 
 Getting the soft debugger/Xamarin setup correctly can be fiddly but it does 
 work.
 It may be possible to debug the managed code by Using Xamarin Studio on OS X 
 or Linux but in my case (as I was building the Managed code assemblies on 
 the Windows VM anyway) it was easiest to run XS on Windows.
 
 Debugging Mono Embedded API
 ===
 
 The embedded managed code can be debugged (including breakpoints and single 
 stepping) using Xamarin Studio.
 
 1. Config OS X app to attach to Mono soft Debugger.
 
 Xamarin Studio must be running on machine with IP 192.168.1.72 (in this case 
 my windows VM)
 [DBManagedEnvironment setRuntimeOptions:@{@address : @192.168.1.72, 
 @port : @1, @loglevel : @0}];
 
 2. Call DBManagedEnvironment +setRuntimeOptions: with IP address and port of 
 Windows VM running the Xamarin Studio debugger.
 
 + (void)setRuntimeOptions:(NSDictionary *)options
 {
 // NOTE: be sure to call this before -initWithDomainName
 
 // for info on these options see man mono
 // the debugger can be configured either as a client or a server
 NSString *address = options[@address]?:@127.0.0.1;
 NSString *port = options[@port]?:@1;
 NSString *server = options[@server]?:@n;
 NSString *suspend = options[@suspend]?:@y;
 NSString *loglevel = options[@loglevel]?:@1;
 NSString *timeout = options[@timeout]?:@10;
 
 NSString *agent = [NSString 
 stringWithFormat:@--debugger-agent=transport=dt_socket,address=%@:%@,server=%@,suspend=%@,loglevel=%@,timeout=%@,
  address, port, server, suspend, loglevel,timeout];
 const char* jit_options[] = {
 --soft-breakpoints,
 [agent UTF8String]
 };
 
 mono_jit_parse_options(2, (char**)jit_options);
 
 mono_debug_init(MONO_DEBUG_FORMAT_MONO);
 }
 
 see 
 https://github.com/ThesaurusSoftware/Dubrovnik/blob/master/Framework/XCode/DBManagedEnvironment.m#L167
 
 
 3. Run app outside of Xcode. The app will pause if the remote debugger is 
 not responding.
 4. Run Xamarin Studio (preconfigure env var to enable the 

Re: [Mono-dev] Compiling Mono with debug symbols to diagnose an issue with embedded Mono 4.0.2.5

[Jonathan Mitchell]

 On 6 Aug 2015, at 15:34, Howard Rubin howard.ru...@hl.konicaminolta.us 
 wrote:
 
 You have to create the generic method. That can be done in C#, which it
 sounds like you're already doing.
 If you'd like to do that in the calling C++/mono (my preferred solution),
 have a look at 
 https://gist.github.com/gedim21/8d86ba8e59ac5d8ed0ee

Thanks for the link.
This is more or less what I am doing - will need to review the code again.
For most of my unit test signatures what I have works fine - only some more 
complex ones are causing trouble

Jonathan
 
 Howard Rubin
 
 -Original Message-
 From: Jonathan Mitchell [mailto:jonat...@mugginsoft.com] 
 Sent: Thursday, August 06, 2015 3:03 AM
 To: Howard Rubin howard.ru...@hl.konicaminolta.us
 Subject: Re: [Mono-dev] Compiling Mono with debug symbols to diagnose an
 issue with embedded Mono 4.0.2.5
 
 On 5 Aug 2015, at 21:55, Howard Rubin howard.ru...@hl.konicaminolta.us
 wrote:
 
 Did the problem situation have to do with generics?
 
 IIRC one of the problem signatures was
 
 public void SendTelemetry(string url, string productCode, params
 KeyValuePairstring, object[] additionalData)
 
 I use a code generator (which can handle moderate range of signatures
 without issue) to parse
 
 https://github.com/ThesaurusSoftware/Dubrovnik/blob/master/dotNET/UnitTests/
 Dubrovnik.UnitTests/ReferenceObject.cs
 
 into
 
 https://github.com/ThesaurusSoftware/Dubrovnik/blob/master/dotNET/UnitTests/
 GeneratedObjC/Dubrovnik_UnitTests_ReferenceObject.m
 
 For the problem signature I had to resort to using a managed helper function
 with a simpler signature.
 
 
 -Original Message-
 From: Jonathan Mitchell [mailto:jonat...@mugginsoft.com]
 Sent: Wednesday, August 05, 2015 1:19 PM
 To: Howard Rubin howard.ru...@hl.konicaminolta.us
 Subject: Re: [Mono-dev] Compiling Mono with debug symbols to diagnose 
 an issue with embedded Mono 4.0.2.5
 
 Hi Howard
 
 Thanks for that.
 I have some code that does something similar but I am still running 
 into situations where I just cannot get the signature figured out.
 IIRC the signature I used agreed with mono_method_full_name() but the 
 method lookup still failed.
 I will take another crack at it and hopefully inspiration will strike.
 
 Thanks again
 
 Jonathan
 
 
 On 5 Aug 2015, at 20:09, Howard Rubin 
 howard.ru...@hl.konicaminolta.us
 wrote:
 
 Hi Jonathan,
 At the risk of defeating my purpose of debugging mono, here’s what I 
 use to “figure out what the correct embedded API function signatures”.
 Hope this helps, Howard Rubin
 
 static void ListMethods(MonoClass* theClass) {
  void* iterM = NULL;
  MonoMethod* mm;
  while ((mm = mono_class_get_methods(theClass, iterM)) != NULL) {
  const char* name = mono_method_get_name(mm);
  printf(mono_method_get_name returned %s \%s\\n, name,
 mono_method_full_name(mm, true));
  }
 }
 
 From: mono-devel-list-boun...@lists.ximian.com
 [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of 
 Alexander Köplinger
 Sent: Wednesday, August 05, 2015 11:19 AM
 To: Mono-devel-list@lists.ximian.com
 Subject: Re: [Mono-dev] Compiling Mono with debug symbols to diagnose 
 an issue with embedded Mono 4.0.2.5
 
 You can build the MDK with
 https://github.com/mono/bockbuild#the-mono-mac-distribution, but I'm 
 not sure if that includes debug symbols (I think it does).
 
 -- Alex
 
 From: jonat...@mugginsoft.com
 Date: Wed, 5 Aug 2015 18:06:37 +0100
 To: Mono-devel-list@lists.ximian.com
 Subject: Re: [Mono-dev] Compiling Mono with debug symbols to 
 diagnose an issue with embedded Mono 4.0.2.5
 
 
 On 5 Aug 2015, at 02:12, jean-michel.perr...@csiro.au wrote:
 
 I am trying to debug C code, mostly to step through the mono 
 runtime
 itself.
 I too would like to debug the Mono runtime itself and so would 
 really,
 really, really like to able to build an MDK with debug symbols and 
 source code references.
 
 Why do I need to debug the runtime?
 I have written an Obj-C  C# bridge utilising the runtime and in 
 some
 situations I cannot figure out what the correct embedded API function 
 signatures are for more complex generic managed methods. Being able to 
 debug the runtime would give me some insight into what is going on in 
 the method signature search process.
 
 That said, I would not at all refuse a howto guide for mixed mode 
 (C
 and C#) debugging on Linux (not possible so far as I know). I may try 
 to give a try on Windows with Visual Studio, but as a fallback option 
 as this issue may not be reproducible on it anyway.
 
 Here is my take on debugging Mono based on working on OS X.
 
 C
 ==
 
 On the Obj-C side (Obj-C is a strict superset of C) I should be able 
 to
 step into the Mono runtime code via the Xcode side if my Mono runtime 
 build supported debug symbols and their source code references. I 
 reckon that most C IDEs should be fit to do the same.
 
 
 C#
 ==
 
 I don’t know of a way to seamlessly debug both C and C# via the same 
 IDE
 on OS X (perhaps VS can

Re: [Mono-dev] Compiling Mono with debug symbols to diagnose an issue with embedded Mono 4.0.2.5

[Jonathan Mitchell]

 On 5 Aug 2015, at 02:12, jean-michel.perr...@csiro.au wrote:
 
 I am trying to debug C code, mostly to step through the mono runtime itself.
I too would like to debug the Mono runtime itself and so would really, really, 
really like to able to build an MDK with debug symbols and source code 
references.

Why do I need to debug the runtime?
I have written an Obj-C  C# bridge utilising the runtime and in some 
situations I cannot figure out what the correct embedded API function 
signatures are for more complex generic managed methods. Being able to debug 
the runtime would give me some insight into what is going on in the method 
signature search process.

  That said, I would not at all refuse a howto guide for mixed mode (C and C#) 
 debugging on Linux (not possible so far as I know). I may try to give a try 
 on Windows with Visual Studio, but as a fallback option as this issue may not 
 be reproducible on it anyway.

Here is my take on debugging Mono based on working on OS X.

C
==

On the Obj-C side (Obj-C is a strict superset of C) I should be able to step 
into the Mono runtime code via the Xcode side if my Mono runtime build 
supported debug symbols and their source code references. I reckon that most C 
IDEs should be fit to do the same.


C#
==

I don’t know of a way to seamlessly debug both C and C# via the same IDE on OS 
X (perhaps VS can so this on windows).
To debug the managed code in my OS X app I do roughly the following (more 
detail follows in the notes below).

1. Configure the OS X app embedded Mono code to use the Mono soft debugger 
(this is a remote capable software debugger that runs over TCP-IP see 
http://www.mono-project.com/docs/advanced/runtime/docs/soft-debugger/).
2. Run my OS X outside of my Xcode IDE. If I don’t do this then the signals 
generated by the debugee tend to get caught by the IDE debugger rather than the 
Mono soft debugger.
3. Fire up Xamarin Studio (XS) on a Windows machine (in my case a Windows VM on 
the same physical machine but a networked base PC should work just fine too).
4. In XS connect to the remote debugger, set breakpoints etc.
5. Exercise the OS X app and trigger breakpoints in XS.

Getting the soft debugger/Xamarin setup correctly can be fiddly but it does 
work.
It may be possible to debug the managed code by Using Xamarin Studio on OS X or 
Linux but in my case (as I was building the Managed code assemblies on the 
Windows VM anyway) it was easiest to run XS on Windows.

Debugging Mono Embedded API
===

The embedded managed code can be debugged (including breakpoints and single 
stepping) using Xamarin Studio.

1. Config OS X app to attach to Mono soft Debugger.

Xamarin Studio must be running on machine with IP 192.168.1.72 (in this case my 
windows VM)
 [DBManagedEnvironment setRuntimeOptions:@{@address : @192.168.1.72, 
@port : @1, @loglevel : @0}];

2. Call DBManagedEnvironment +setRuntimeOptions: with IP address and port of 
Windows VM running the Xamarin Studio debugger.

+ (void)setRuntimeOptions:(NSDictionary *)options
{
// NOTE: be sure to call this before -initWithDomainName

// for info on these options see man mono
// the debugger can be configured either as a client or a server
NSString *address = options[@address]?:@127.0.0.1;
NSString *port = options[@port]?:@1;
NSString *server = options[@server]?:@n;
NSString *suspend = options[@suspend]?:@y;
NSString *loglevel = options[@loglevel]?:@1;
NSString *timeout = options[@timeout]?:@10;

NSString *agent = [NSString 
stringWithFormat:@--debugger-agent=transport=dt_socket,address=%@:%@,server=%@,suspend=%@,loglevel=%@,timeout=%@,
 address, port, server, suspend, loglevel,timeout];
const char* jit_options[] = {
--soft-breakpoints,
[agent UTF8String]
};

mono_jit_parse_options(2, (char**)jit_options);

mono_debug_init(MONO_DEBUG_FORMAT_MONO);
}

see 
https://github.com/ThesaurusSoftware/Dubrovnik/blob/master/Framework/XCode/DBManagedEnvironment.m#L167


3. Run app outside of Xcode. The app will pause if the remote debugger is not 
responding.
4. Run Xamarin Studio (preconfigure env var to enable the soft debug menu if it 
is not visible) on the VM and load the solution being debugged on OS X.
5. Set start up project as appropriate (May be better to have a dummy exe 
project rather than rebuild this all the time).
6. Select Run - Run with - Custom command Mono soft debugger.
7. Enter IP address and port.
8. Click Listen.
9. Set breakpoints as normal.

Notes on Use of the Mono Soft Debugger
==

See http://www.jeffongames.com/2012/03/debugging-embedded-mono/
http://mono.1490590.n4.nabble.com/remote-debugging-a-hello-world-application-td4591791.html

The debugee should connect to the debugger on the configured listener IP and 
port.
The Windows firewall will need to allow the incoming connection.
To check if the connection is up and 

Re: [Mono-dev] Compiling Mono with debug symbols to diagnose an issue with embedded Mono 4.0.2.5

[Jonathan Mitchell]

 On 4 Aug 2015, at 08:26, jean-michel.perr...@csiro.au wrote:
 
 * build/install mono from source (I know that) but with debug symbols
I would second this. 

 * If the above is done, can I use MonoDevelop or other graphical front-end to 
 attach to the process with embedded Mono and step through code with GDB. I 
 can already attach  MonoDevelop to the R process and catch the crash, but the 
 call stack is devoid of info and reference to the source code (presumably 
 lacking the former debug symbols?)

Are you trying to debug the managed code or the embedded C API?

Jonathan













___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] OS X 64 bit stuff

[Jonathan Mitchell]

HI

Some of us use 64 bit Mono on OS X.
The current binary download is currently deficient by 32bits.

So:

1. Is there a timeline for a 64 bit OS X framework release? A few months ago 
the answer was no.

2. I think that Xamarin.mac supports 64 bits. Does this use a discrete 64 
library build as opposed to a standard OS X framework bundle?

3. The OS X mono framework is apparently built with 
https://github.com/mono/bockbuild. That repo his pretty opaque. 
https://github.com/mono/bockbuild/blob/master/bockbuild/darwinprofile.py looks 
like it might be able to handle a 64 bit build. Am I on the right track there?

Jonathan














___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Building Mono MDK

[Jonathan Mitchell]

I would like to build a 64 bit version of the Mono MDK for OS X.
It looks as if the current Mono OS X release is still 32 bit only.

How do I configure an MDK build?

Thanks

Jonathan













___
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 Embedded Platform

[Jonathan Mitchell]

 On 21 Nov 2014, at 07:05, techi eth techi...@gmail.com wrote:
 
 Hey,
 
 
 I have following point to check before start.
 
 1)  1) How can I achieve small footprint from mono. I have followed the 
 below link but it produces install directory which is more than 100 MB with 
 mono 3.10.0.
 

 I know nothing about embedded platforms but I do know this.

I run a 64 bit Mono run time out of my OS X app bundle.
The omits all build tool chain stuff and consists of libmono, mscorlib 4 + 4.5, 
some configs and the 14 Mono assemblies required by my managed code at runtime.
I use the Mono assemblies as is i.e: I don’t tinker with the assemblies to 
reduce code size.

This comes in at 17MB for my usage case minimal Mono runtime environment.
My actual application managed code is then additional to this.

Jonathan




___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list