gcc4cli-devel Mailing List for GCC for CLI

1) Linktime prototype fixing patch has been committed into the clibinutils repository (it is no longer necessary to apply any patch to the binutils)

2) Mono.Cecil@147644 files have been copied into the repository. Why?
  Mono moved to git and the ancient svn-based version system is no longer available. We are not able to retrieve the revision under which clibinutil works (and the new one is very different). I considered that the easiest way to guarantee that clibinutils (thus gcc4cli) will work is to include Mono.Cecil@147644 in the clibinutils repository.
  Build instructions (http://gcc.gnu.org/viewcvs/branches/st/README?view=markup) have been updated too.

Hi all,

This mail summarizes how to build and run SPEC2000 with gcc4cli:

* Patchs:
  spec2000.patchs.tgz contains all the patchs that must be applied to each C SPEC2000 benchmark (including the 177.gcc one, which is not still working).

* Build flags:
  Add the flags "-fno-tree-vectorize -DGCC4CLI" to your build command. 

David Yuste

At this point, every C benchmark but 253.perlbmk (which uses C++) and 176.gcc (which is mess) is working. In some future, I could do some efforts to support 176.gcc, but for the moment I will skeep the benchmark. Also, I am missing some help with this benchmark.

Tomorrow I will pack together all the patchs that must be applied (some of them have been simplified after introducing link time prototype fixing), and I will try to update the repository of the binutils ld with the new version (the one implementing link time prototype fixing).

Another important issue that we must do is to merge with the new version of Cecil, that is to update the binutils ld driver to use the new version of Mono.Cecil.

The set of benchmarks that work:
164.gzip
175.vpr
177.mesa
179.arts
181.mcf
183.equake
186.crafty
188.amp
197.parser
254.gap
255.vortex
256.bzip2
300.twolf
 
The set of benchmarks that doesn't work because of known issues:
253.perlbmk: C++
 
The set of benchmarks that doesn't work because of unknown issues:
176.gcc: too many bugs in the benchmark, difficult to debug

Hi,

  After doing some changes, 254.gap is working: it runs native, builds to CIL via cli-be, runs in MONO and builds into native again via cli-fe producing a correct binary.

  In order to run it, apply the patch, and use the last version of cli-be (remember to build and install libstd), binutils and cli-fe

David

A new benchmark is working (255.vortex). I don't think that the three remaining will do in a short term.

The set of benchmarks that work:
164.gzip
175.vpr
177.mesa
179.arts
181.mcf
183.equake
186.crafty
188.amp
197.parser
255.vortex
256.bzip2
300.twolf
 
The set of benchmarks that doesn't work because of known issues:
253.perlbmk: C++
254.gap: longjump, complex input/output
 
The set of benchmarks that doesn't work because of unknown issues:
176.gcc: too much bugs in the benchmark, difficult to debug


----- Mail original -----
> De: "David Yuste" <dav...@in...>
> À: gcc...@li...
> Envoyé: Vendredi 27 Mai 2011 17:20:39
> Objet: [Gcc4cli-devel] SPEC2000: status
> The set of benchmarks that work:
> 164.gzip
> 175.vpr
> 177.mesa
> 179.arts
> 181.mcf
> 183.equake
> 186.crafty
> 188.amp
> 197.parser
> 256.bzip2
> 300.twolf
> 
> The set of benchmarks that doesn't work because of known issues:
> 253.perlbmk: C++
> 254.gap: longjump, complex input/output
> 
> The set of benchmarks that doesn't work because of unknown issues:
> 176.gcc: too much bugs in the benchmark, difficult to debug
> 300.twolf: it fails even with the native version (probably it is my
> fault I could fix one with little effort)
> 
> ** My plans are to try to run 300.twolf, pack all the needed patchs
> (to have a bit of order), and apply the binutils:ld changes to the
> repository.
> 
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Gcc4cli-devel mailing list
> Gcc...@li...
> https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel

In order to make the benchmark spec2000:255.vortex work, both changes have been implemented.
Currently the benchmark 255.vortex is working.

----- Mail original -----
> De: "David Yuste" <dav...@in...>
> À: gcc...@li...
> Envoyé: Vendredi 27 Mai 2011 10:59:54
> Objet: [Gcc4cli-devel] CLI-BE (rev 174324): COND_EXPR comparing pointers
> Hi,
> 
> Comparison (gcc's COND_EXPR) between pointers was not implemented. I
> just let it fall into the integer comparison.
> 
> Affected benchmarks: SPEC2000:300.twolf
> 
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Gcc4cli-devel mailing list
> Gcc...@li...
> https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel

The set of benchmarks that work:
164.gzip
175.vpr
177.mesa
179.arts
181.mcf
183.equake
186.crafty
188.amp
197.parser
256.bzip2
300.twolf

The set of benchmarks that doesn't work because of known issues:
253.perlbmk: C++
254.gap: longjump, complex input/output

The set of benchmarks that doesn't work because of unknown issues:
176.gcc: too much bugs in the benchmark, difficult to debug
300.twolf: it fails even with the native version (probably it is my fault I could fix one with little effort)

** My plans are to try to run 300.twolf, pack all the needed patchs (to have a bit of order), and apply the binutils:ld changes to the repository.

The benchmark compiles in cli-be, cli-fe, runs native, mono and gcil-native.

You must:
- Apply the patch: we do not still properly handle global variables (not extern, not static, shared among different compilation units), thus I just add "extern" to many of the shared variables in the benchmark.
- Use the last version of cli-be (rev 174324), which implements pointer comparison
- Use the binutils:ld version implementing link time prototype fixing.

Hi,

Comparison (gcc's COND_EXPR) between pointers was not implemented. I just let it fall into the integer comparison.

Affected benchmarks: SPEC2000:300.twolf

Hi Simone,

I believe you are reading this. And I imagine you have a working installation of 
ILDJIT. If we send you a CIL binary, could you give it a quick try?

David: you can try a genuine .NET on Windows machines (rdesktop meaban).

Thanks for all this!

--
Erven.


Le 18/05/2011 18:06, David Yuste a écrit :
> At this point*, 176.gcc is partially working.
>
>    It builds to CIL (cli-be), and then to native via gcil (cli-fe). The gcil-binary runs without problem, but there are small differences in the output of the program regarding the native-binary output. I will try to find out why.
>
>    Most of the efforts to make it run have been to to implement varadic arguments in gcil. Ironically, the CIL version crashes in mono due to variadic arguments. If somebody has access to a .NET environment, it would help getting feedback about this problem (I can just try with Mono).
>
> *In order to get these results you must:
>
> - Apply the attached patch. It disables some features that are not working in gcc4cli, also it fixes some actual bugs.
> - Use the last version of cli-be (remember to get into gcc-be:gcc/libstd, and make&&make install). Required in order to use new libraries in stdlib, and some fixed prototypes
> - Use the last version of cli-fe. Required to compile varadic argument functions.
> - Use the last version of cil-binutils (apply the *last* patch in "Mono.Cecil: Fixing wrong prototypes at link time"). Required, because many prototypes are fixed at linktime.
> - Build using the following flags:
>    CFLAGS+=-fno-tree-vectorize -DGCC4CLI -D__linux__ -DUSG
>    LDFLAGS+=-lm -lstd mismatch
>
>
> David Yuste
>

At this point*, 176.gcc is partially working.

  It builds to CIL (cli-be), and then to native via gcil (cli-fe). The gcil-binary runs without problem, but there are small differences in the output of the program regarding the native-binary output. I will try to find out why.

  Most of the efforts to make it run have been to to implement varadic arguments in gcil. Ironically, the CIL version crashes in mono due to variadic arguments. If somebody has access to a .NET environment, it would help getting feedback about this problem (I can just try with Mono).

*In order to get these results you must:

- Apply the attached patch. It disables some features that are not working in gcc4cli, also it fixes some actual bugs.
- Use the last version of cli-be (remember to get into gcc-be:gcc/libstd, and make&&make install). Required in order to use new libraries in stdlib, and some fixed prototypes
- Use the last version of cli-fe. Required to compile varadic argument functions.
- Use the last version of cil-binutils (apply the *last* patch in "Mono.Cecil: Fixing wrong prototypes at link time"). Required, because many prototypes are fixed at linktime.
- Build using the following flags: 
  CFLAGS+=-fno-tree-vectorize -DGCC4CLI -D__linux__ -DUSG
  LDFLAGS+=-lm -lstd mismatch 


David Yuste

Hi,

  I updated the link time mechanism for fixing prototypes. Now it works without problems and it detects bugs such as calls with incorrect number of arguments in the source code.
  Thanks to it I was able to identify several actual bugs in benchmarks such as SPEC2000:176.gcc, and properly fix them.

  Soon I will update the actual driver implementation. Any way, we must merge with the new Cecil.

David

----- Mail original -----
> De: "David Yuste" <dav...@in...>
> À: gcc...@li...
> Envoyé: Vendredi 6 Mai 2011 18:26:32
> Objet: [Gcc4cli-devel] Mono.Cecil: Fixing wrong prototypes at link time
> Hi,
> 
> I developed a small method to fix prototypes at link time (thus, it is
> implemented in Mono.Cecil).
> 
> Basically, it compares the signature of each function involved in a
> *direct* call with the signature of the corresponding function
> definition. If they differ (right now I only care about the return
> value), it updates the signature in the call statement. In addition,
> if the call signature was "not void" typed, while the actual function
> is "void" typed, the next instruction is checked. If this instruction
> is "pop", it is deleted (thus we avoid an incorrect stack error).
> 
> As limitation, it doesn't apply to indirect calls (since we don't know
> the callee function).
> 
> Since I don't have write access to the Mono.Cecil repository (and also
> we work on a version, why?), I just attach the patch. I'm still
> experiencing with it, but it worked properly in all my tests.
> 
> Finally, just an example of the problem and the solution (introduced
> at link time):
> 
> *** Source code
> file1.c
> ---
> void foo (char ** argv) {
> }
> ---
> 
> file2.c
> ---
> int main (int argc, char ** argv) {
> foo (argv); -> guessed as 'int foo (char**)'
> }
> ---
> 
> *** After cil32
> file1.cil32
> ---
> .method public static void 'foo' (int8 * * 'argv') cil managed
> {
> ...
> }
> ---
> 
> file2.cil32
> ---
> .method public static int32 'main' (int32 'argc', int8 * * 'argv') cil
> managed {
> ...
> call int32 [ExternalAssembly]ExternalAssembly::'no_prototype' (native
> int)
> pop
> ldc.i4 0
> ...
> }
> ---
> 
> *** After link (with our pass)
> .method public static
> default int32 main (int32 argc, int8** argv)
> cil managed
> {
> // Method begins at RVA 0x2084
> // Code size 9 (0x9)
> .maxstack 8
> IL_0000: ldarg.1
> IL_0001: conv.i
> IL_0002: call void test::foo(int8**) //Fixed return value
> IL_0007: ldc.i4.0 //Pop removed, the stack is correct
> IL_0008: ret
> } // end of method test::main
> 
> 
> David
> 
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today. Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> Gcc4cli-devel mailing list
> Gcc...@li...
> https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel

Hi,
  
  I just provided a partial implementation of signals, doing nothing in Mono, and calling to the host library (through the library wrapper) in gcil.

  Affected SPEC2000 benchmarks: gcc

David

Hi,

At revision 173852 variadic arguments are working in GCIL. It means that cli-be CIL binaries, produced from C code *implementing* variadic functions, can be compiled into native by using GCIL.

David

Actually, it seems that the problem is that function parser_preparse_method() is not handling the corresponding mono code.

After looking at the standard, the semantic of 'initobj <type>' is to initialize the object pointed by the address on the top of the stack.
"To initialize" seems to mean "to set to zero". First I thought that it could be implemented with "memset". But since we are handling objects, may be we will flush any vtable at the start of the object.

But wait... vtables in C? After discussing with Erven, we found that this instruction makes no sense in GCIL (at least if we only handle CLI-BE code). The only scenario is the one where 'varargs' is involved. The back-end emits CLI library code, including the argiterator (this is the variable to be initialized). But, what should we do with that, once we are in gcil going back to gimple?

The idea is to (carefully) omit 'iniobj', and handle iterators as some kind of builtins, so that we can translate CIL-varargs code into stdarg-varargs code.

Next monday, I will start working on it, but any clue about the current implementation (if any) would be welcome.

Thanks,
David



----- Mail original -----
> De: "David Yuste" <dav...@in...>
> À: gcc...@li...
> Envoyé: Vendredi 13 Mai 2011 17:57:35
> Objet: [Gcc4cli-devel] Unsupported feature 'intiobj'
> Hi,
> 
> I have problems to compile methods using varargs (the problem is not
> in the call side, but in the implementation of the function with
> varargs).
> gcil fails to compile them and asserts "method 'whatever ()' not
> compiled, unsupported feature 'initobj'."
> 
> I am trying to verify that it is not a problem with my mono
> configuration, but in the meantime, does anybody have any idea?
> 
> Thanks,
> David
> 
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Gcc4cli-devel mailing list
> Gcc...@li...
> https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel

Hi,

I have problems to compile methods using varargs (the problem is not in the call side, but in the implementation of the function with varargs).
gcil fails to compile them and asserts "method 'whatever ()' not compiled, unsupported feature 'initobj'."

I am trying to verify that it is not a problem with my mono configuration, but in the meantime, does anybody have any idea?

Thanks,
David

Le 06/05/2011 18:26, David Yuste a écrit :
> Hi,
>
> I developed a small method to fix prototypes at link time (thus, it is implemented in Mono.Cecil).
>
> Basically, it compares the signature of each function involved in a *direct* call with the signature of the corresponding function definition. If they differ (right now I only care about the return value), it updates the signature in the call statement. In addition, if the call signature was "not void" typed, while the actual function is "void" typed, the next instruction is checked. If this instruction is "pop", it is deleted (thus we avoid an incorrect stack error).
>
> As limitation, it doesn't apply to indirect calls (since we don't know the callee function).
>
> Since I don't have write access to the Mono.Cecil repository (and also we work on a version, why?),


Just to make sure we know what we work on.
It could be interesting to see if the latest version works for us (ie no change 
in API, etc.) It could actually also be that it fixes the problem you discovered 
with the range of branch instructions.

--
Erven.


  I just attach the patch. I'm still experiencing with it, but it worked 
properly in all my tests.
>
> Finally, just an example of the problem and the solution (introduced at link time):
>
> *** Source code
>    file1.c
>    ---
>    void foo (char ** argv) {
>    }
>    ---
>
>    file2.c
>    ---
>    int main (int argc, char ** argv) {
>      foo (argv);  ->  guessed as 'int foo (char**)'
>    }
>    ---
>
> *** After cil32
>    file1.cil32
>    ---
>    .method public static void 'foo' (int8 * * 'argv') cil managed
>    {
>     ...
>    }
>    ---
>
>    file2.cil32
>    ---
>    .method public static int32 'main' (int32 'argc', int8 * * 'argv') cil managed {
>      ...
>      call    int32 [ExternalAssembly]ExternalAssembly::'no_prototype' (native int)
>      pop
>      ldc.i4  0
>      ...
>    }
>    ---
>
> *** After link (with our pass)
>    .method public static
>      default int32 main (int32 argc, int8** argv)
>      cil managed
>    {
>      // Method begins at RVA 0x2084
>      // Code size 9 (0x9)
>      .maxstack 8
>      IL_0000:   ldarg.1
>      IL_0001:   conv.i
>      IL_0002:   call void test::foo(int8**)   //Fixed return value
>      IL_0007:   ldc.i4.0  //Pop removed, the stack is correct
>      IL_0008:   ret
>    } // end of method test::main
>
>
> David

Hi,

I developed a small method to fix prototypes at link time (thus, it is implemented in Mono.Cecil).

Basically, it compares the signature of each function involved in a *direct* call with the signature of the corresponding function definition. If they differ (right now I only care about the return value), it updates the signature in the call statement. In addition, if the call signature was "not void" typed, while the actual function is "void" typed, the next instruction is checked. If this instruction is "pop", it is deleted (thus we avoid an incorrect stack error).

As limitation, it doesn't apply to indirect calls (since we don't know the callee function).

Since I don't have write access to the Mono.Cecil repository (and also we work on a version, why?), I just attach the patch. I'm still experiencing with it, but it worked properly in all my tests.

Finally, just an example of the problem and the solution (introduced at link time):

*** Source code
  file1.c
  ---
  void foo (char ** argv) {
  }
  ---

  file2.c
  ---
  int main (int argc, char ** argv) {
    foo (argv);  -> guessed as 'int foo (char**)'
  }
  ---

*** After cil32
  file1.cil32
  ---
  .method public static void 'foo' (int8 * * 'argv') cil managed
  {
   ...
  }
  ---

  file2.cil32
  ---
  .method public static int32 'main' (int32 'argc', int8 * * 'argv') cil managed {
    ...
    call    int32 [ExternalAssembly]ExternalAssembly::'no_prototype' (native int)
    pop
    ldc.i4  0
    ...
  }
  ---

*** After link (with our pass)
  .method public static
    default int32 main (int32 argc, int8** argv)
    cil managed
  {
    // Method begins at RVA 0x2084
    // Code size 9 (0x9)
    .maxstack 8
    IL_0000:   ldarg.1
    IL_0001:   conv.i
    IL_0002:   call void test::foo(int8**)   //Fixed return value
    IL_0007:   ldc.i4.0  //Pop removed, the stack is correct
    IL_0008:   ret
  } // end of method test::main


David

This patch makes cli-be to automatically fix some missing prototypes that can be found in old style C code (unfortunately, it is very common in SPEC).

It applies when there is no explicit prototype, but DECL_ARGUMENTS still holds the actual list of arguments. This is the case of the following declaration:
    
       void foo (arg)
         double arg;
       { }

       // Somewhere below
       foo (10);   --> guessed as 'int foo (int)'

In this situations, we restore the prototype from the function definition. That is, we update TREE_TYPE of the corresponding function with a new type description built from the actual function definition. (Note that in absence of prototype, TYPE_ARG_TYPES (TREE_TYPE (func)) is null)

The changes are in:
  missing-protos.c:
    The function 'fix_missing_prototype()' is implemented here. This function performs the actual work.
    The already existing pass missing_protos is also implemented in this file. I don't really understand what this pass is doing, or even if it can conflict with my proposal (does any one know?). 
    I just chose this file because the name suggest a good emplacement for the new function, even if this pass is doing something very different.

  gimple-to-cil.c:
    gimple_to_cil() -> Fix current_function_decl prototype if applies (some times it does).
    gen_call_expr() -> Fix callee prototype.
      -- Some "name resolution" errors are avoided
      -- The arguments are properly cast (when necessary)
  
  emit-cil.c:
    dump_fun_type() -> fix the prototype of the function being dumped.
       -- Some "name resolution" errors are avoided

I hope to do not introduce any side effect as consequence of this patch. I already did many tests, if somebody finds something weird, please tell me.


David

188.ammp is working:
* runs native
* builds to cil (cil32)
*   runs in mono (it should run in .NET as well)
* builds from cil to native (gcil)
*   runs in cil-to-native (gcil)

You must:

1) Apply the Mono.Cecil.Cil patch for long jump optimization:
 This benchmark was experiencing the bug that I just reported in the list as "Mono.Cecil.Cil: OptimizeBranch bug"
 Any way, I attached it again. Just download it and apply to your Mono.Cecil.Cil, which should be in <cli-be>/gcc-src/binutils/tools/Mono.Cecil
 (if you have problems to apply it, just edit the file Mono.Cecil.Cil/MethodBody.cs and add "return false;" right after the start of OptimizeBranch())


2) Fix deprecated prototypes:
 This benchmark is coded in a very old fashion. Most of the prototypes are missing or they are different than the actual ones. I implemented a script to update the code:

 * Uncompresss 188.amp.fix_prototypes.patch.tgz into your 188.amp source folder. It contains:

   __autogen_prototypes.h -> the set of correct prototypes used in the program
   <file.c>.missing_prototypes -> a per file list of each prototype that is missing
   fix_prototypes.sh -> a bash script that will patch the source code (everything will be backed up before)

 * Run ./fix_prototypes.sh

 After this, your folder should contain a bunch of files like <file.c>.protos.h, and each file.c should have been modified. Now you can build everythinig (if you use the flags that I point right below)


3) Use these building flags:
 You must use the following flags:
 CFLAGS += -DSPEC_CPU2000 -DGCC4CLI -DNEWCCALL


David

Hi all,

I found a bug in Mono.Cecil.Cil. The bug arises after branch optimization, producing, in some scenarios, wrong code. However, the origin of the problem may be at some other function.

In MethodBody.cs::OptimizeBranch(), some long jumps are optimized into short jumps, because their offsets are small enough.
However, at some point, the instruction stream between the target and the jump instruction is modified. The new jump offset becomes longer than a short jump. The modification is not reported and the jump is any way optimized into short jump. It incurs into an overflow in the jump address, so jumping into some incorrect address (I was able to detect it when the target was out of the function).

We should identify the source of the problem and fix it. Right now I only skeep this optimization (that is what the patch is doing).

It can be reproduced with the benchmark SPEC2000:188.ammp. The code produced by cli-be is correct just before linking. After linking, the wrong address appears. After applying this "patch", it works.

David

186.crafty is working:
* runs native
* builds to cil (cil32)
*   runs in mono (it should run in .NET as well)
* builds from cil to native (gcil)
*   runs in cil-to-native (gcil)

Compiler changes (just 'svn update' and build both cli-be and cli-fe -remember to rebuild cli-be:libstd.so-)
 *New features in libstd:
    new headers: sys/times.h, pwd.h
    new functions: sysconf, times, getuid, getpwuid, fileno
    defined EINTR
 *New patchs:
    Patch: (back end) broken function-static variables in specialized functions
    Patch: (front end) broken ldarga

Benchmark patch (apply the changes in the attached patch, it is git ready, but probably you must do it manually)
 When GCC4CLI is defined:
 *Function 'select' is not used
 *Simplified input methods in utility.c:Read() (it makes no difference for the actual benchmark behavior)
 *Headers signal.h, ioctl.h. and select.h are not used 
 *Variable pawn_score is defined as extern (when GCC4CLI is defined)
   Reason: global variables in C (not extern, just global scope), are not properly translated into cil, causing multiple definitions of the same symbol at link time. We did already discuss it and there is no obvious solution.
 *Using always fgets instead of gets. gets is dangerous and not recommended, but in addition it seems broken in our implementation (pending to fix it)

Benchmark compilation:
  cil32 - Required extra flags: -fno-tree-vectorize -DGCC4CLI [-DSPEC_CPU2000]

**The problem:
paser_emit_ldarga() takes the address of a given variable. The emitted GENERIC looks like:
  temp = &arg;

But the variable arg is not marked as addressable. It causes gimplifier to create a temporary variable in the following way:
  arg.1 = arg;
  temp = &arg.1;

Thus, the taken address belongs to arg.1 and not to arg. It means that writes through *temp will not affect arg.

**Fixed:
It has been fixed. I just added mark_addressable(var) in parser_emit_ldarga();

**Affected benchmarks: 186.crafty (at least, probably most of the benchmarks).

This patch provides an abstraction for POSIX users management. I want to remark that it doesn't use the actual underlying UIDs of users (because they may not exist, if running in Windows for instance). Instead, UIDs are arbitrary values generated inside the library. If you plan to read an UID (a real one) from file and call getpwuid (for instance), this code is not for you.

New libstd headers:
  libstd/include/pwd.h

New libstd functions (implemented in libstd/src/_users.c):
  getuid()
  geteuid() 
  getpwuid()
  getpwnam()

New core functions matching the previous one in a marshal-safe way. The __host.c ones are just wrappers. The MSCorelibWrapper.cs ones behave as follows:
  getuid() - Returns (or allocate at first time) a UID for current user
  geteuid() - Just calls the previous one. Effective user is assumed current user (may be it is related to Impersonation in .NET, I have to research about this).
  getpwuid() - Gets the .NET user name from the UID and behave and behaves as getpwnam()
  getpwnam() - Gets (or allocate at first time) a UID for the given user. Given the user name, returns null as password, user login as real name (we could research on this), home path as home path, null as shell.

  In addition, some private functions are implemented to manage UID and user name mappings. The useful ones: GetNameFromUid and GetUidFromName.

The behavior can be tested with test_users.c (build and run both in mono and in native through gcil)

Affected benchmarks: 186.crafty

This patch fixes the following problem:

Functions resulting from "function specilization" may contain references to
function-static variables in the original function.
Since this variables are class-static in CIL, they are renamed -at some
point- by adding a suffix (to ensure that they are unique).

This renaming happens while processing the function in which they are declared.
In the case of specialized functions, references to these variables MAY BE found
before they are renamed.

This patch detects these situations (in emit-cil.c:dump_decl_name) and prints the
corresponding suffix after the variable name.

A better patch should move the renaming process to some IPA pass.

Affected benchmarks: 186.crafty