[Mono-dev] gmcs and The Future

[Евгений Гришуль]

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>

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090205/521eafb7/attachment-0001.html 
-------------- next part --------------
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
-------------- next part --------------
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