[Mono-dev] gmcs and The Future

[Marek Safar]

Hi,

Thank you for tracking this down. Could you fill a bug report at 
http://www.mono-project.com/Bugs so we can address the issue.

Marek
> I try to use these voodoo keywords and have a small report:
>
> 1) gmcs currently supports only __arglist keyword, but sometimes 
> generates incorrect CIL. That code works while compiling with csc.exe, 
> but leads to segmentation fault after gmsc (I try it on Mac OS 10.5, 
> Mono 2.2 ):
> ================== CODE ===========================
>  private static void TestArglistMethod()
> {
>   ArglistMethod( __arglist( 1, 2, 3 ) );
> }
>  
> private static void ArglistMethod(__arglist )
> {
>   var iter = new ArgIterator( __arglist );
>  
>   for( var n = iter.GetRemainingCount(); n > 0; n-- )
>   Console.WriteLine( TypedReference.ToObject( iter.GetNextArg() ) );
> }
> ===================================================
> 2) Mono VES currently supports mkrefany, refanyval, refanytype, 
> arglist instructions for non-P/Invoke scenario.
>
> 3) Mono JIT & P/Invoke layer don't like __arglist parameters and 
> reports something like this: Invalid IL code in 
> NObjective.Program:Main (string[]): IL_0021: ret
> ================== CODE ===========================
> [DllImport( "libc.dylib" )]
> public extern static void printf( string format, __arglist );
>
> ...
>  
> printf( "ytu", __arglist( "44" ) );
> ===================================================
> If compiler will be able generate correct CIL it will be useful for 
> debugging future P/Invoke layer that will able to work with __arglist
> NObjective contains about of 43000 generated methods (generated from 
> Objective-C method signatures) accessible by user that looks like:
>
> ================== CODE ===========================
> unsafe public static bool writeToURL_atomically_( this NSData ___this, 
> NSURL url, bool atomically ) {
>   RuntimeObject ___occuredException;
>   var ___result = NativeMethods.writeToURL_atomically_( ___this, 
> CachedSelectors.writeToURL_atomically_, out ___occuredException, 
> sizeof( NSURL ) + sizeof( bool ), url, atomically );
>   if( ___occuredException != RuntimeObject.Null ) throw 
> RuntimeException.Create( ___occuredException );  
>   return ___result;
> }
>
> unsafe public static bool writeToURL_options_error_( this NSData 
> ___this, NSURL url, uint options, ref NSError error ) {
>   RuntimeObject ___occuredException;
>   var ___result = NativeMethods.writeToURL_options_error_( ___this, 
> CachedSelectors.writeToURL_options_error_, out ___occuredException, 
> sizeof( NSURL ) + sizeof( uint ) + sizeof( IntPtr ), url, options, ref 
> error );
>   if( ___occuredException != RuntimeObject.Null ) throw 
> RuntimeException.Create( ___occuredException ); 
>   return ___result;
> }
> ===================================================
> Each generated method have a generated P/Invoke counterpart with same 
> entry point and nearly same signature (another 43000 methods!):
> ================== CODE ===========================
> [DllImport(Runtime.InteropLibrary, EntryPoint = "objc_msgSend_eh2")]
> public static extern bool writeToURL_atomically_( RuntimeObject 
> ___object, Selector ___selector, out RuntimeObject 
> ___occuredException, int ___stackSize, NSURL url, bool atomically );
>
> [DllImport(Runtime.InteropLibrary, EntryPoint = "objc_msgSend_eh2")]
> public static extern bool writeToURL_options_error_( RuntimeObject 
> ___object, Selector ___selector, out RuntimeObject 
> ___occuredException, int ___stackSize, NSURL url, uint options, ref 
> NSError error );
> ===================================================
>
> With proper __arglist support in VES/gmcs unnecessary P/Invokes can be 
> easily removed ( -43000 methods = assembly will hold much less 
> metadata ) and calls redirected to SINGLE __arglist method:
>  
> ================== CODE ===========================
> unsafe public static bool writeToURL_atomically_( this NSData ___this, 
> NSURL url, bool atomically ) {
>   RuntimeObject ___occuredException;
>   var ___result = NativeMethods.FutureArglistMethod( ___this, 
> CachedSelectors.writeToURL_atomically_, out ___occuredException, 
> sizeof( NSURL ) + sizeof( bool ), __arglist( url, atomically ) );
>   if( ___occuredException != RuntimeObject.Null ) throw 
> RuntimeException.Create( ___occuredException );  
>   return ___result;
> }
>
> unsafe public static bool writeToURL_options_error_( this NSData 
> ___this, NSURL url, uint options, ref NSError error ) {
>   RuntimeObject ___occuredException;
>   var ___result = NativeMethods.FutureArglistMethod( ___this, 
> CachedSelectors.writeToURL_options_error_, out ___occuredException, 
> sizeof( NSURL ) + sizeof( uint ) + sizeof( IntPtr ), __arglist( url, 
> options, ref error ) );
>   if( ___occuredException != RuntimeObject.Null ) throw 
> RuntimeException.Create( ___occuredException ); 
>   return ___result;
> }
>
> ...
>  
>
> [DllImport(Runtime.InteropLibrary, EntryPoint = "objc_msgSend_eh2")]
> public static extern bool FutureArglistMethod( RuntimeObject 
> ___object, Selector ___selector, out RuntimeObject 
> ___occuredException, int ___stackSize, __arglist );
> ===================================================
>
> WBR,
> Eugeny Grishul
>
>
> 2009/2/5 Miguel de Icaza <miguel at novell.com <mailto:miguel at novell.com>>
>
>     Hello,
>
>     > > gmcs Compiler already not 100% compatible with csc - __arglist
>     > > <http://bartdesmet.net/blogs/bart/archive/2006/09/28/4473.aspx>,
>     > > __refvalue
>     > > <http://bartdesmet.net/blogs/bart/archive/2006/09/28/4473.aspx>,
>     > > __makeref
>     > >
>     <http://bartdesmet.net/blogs/bart/archive/2006/09/28/4473.aspx> not
>     > > supported ( it can significatly reduce P/Invokes in bridging
>     code of
>     > > NObjective <http://code.google.com/p/nobjective/>)
>     > >
>     > __arglist is fully supported.
>     >
>     > We have not implemented __reftype/__makeref mainly because
>     nobody raised
>     > any interested in these undocumented keyword. If you missing this
>     > support please fill a bug report.
>
>     I agree.   Until today I did not even know those existed.
>
>     What is their use case and how do you use these in NObjective?  I
>     would
>     like to know more about this.
>
>     As Marek said, please file a bug report, that will help us track this
>     task.
>
>     miguel
>
>
>
>
> -- 
> WBR,
> Eugeny Grishul
> ------------------------------------------------------------------------
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list