gcc4cli-devel — Discussions on development issues of the project

[Gcc4cli-devel] CLI-BE (rev 170437): Implemented libstd:sysconf

[David Y. <dav...@in...>]

New header include/bits/confname.h (list of variable names)
New libstd function sysconf in src/sysconf.c
 Just calls to the core function getsysconf
New core function: getsysconf
 - In src/MSCorelibWrapper.cs: it only works for the variable _SC_CLK_TCK (the one used by the benchmark 186.crafty)
 - In src/__host.c: just a wrapper to the system one

Affected benchmarks 186.crafty

[Gcc4cli-devel] CLI-BE (rev 170369 and 170401): Implemented libstd:times

[David Y. <dav...@in...>]

Function "times" implemented in libstd.
- New header libstd/include/sys/times.h, defining struct tms.

- New core function: gettimes(clock_t* clks, clock_t* tms_utime, ..., clock_t* tms_cstime)
  - Implemetation in MSCorelibWrapper:
     *tms_utime and tms_stime are expressed in centiseconds (it seems to be the
     unit used by 'times', I didn't find any explication, but it matchs).
     *tms_cstime and tms_cutime are set to 0. It seems impossible to check for
     child processes. The only way is using the PerformanceCounter "Creating Process
     Id", but it doesn't seem to be implemented in Mono.
     *clks (for 'times' return value) is set to clock(). It should be ok:
     (http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_19.html)

  - Implementation in __host.c
    Just a wrapper to the system 'times'.

Affected benchmarks: 186.crafty

[Gcc4cli-devel] 'select' and Spec2000

[David Y. <dav...@in...>]

Hi all,

I've been almost a week dealing with select. Finally my conclusion is that there is no way to get an equivalent behavior in .NET:

** The problem

'select' takes three sets of file descriptors and blocks until a given time out expires -may be null: block indefinitely, or 0.0s: not blocking-, or an "event" occurs in some of the files in the sets. Such an event can be "ready to read" for the first set, "ready to write" for the second, and "exception on file" for the third (sockets??).
The 'pselect' is still funnier. It also involves signals.

I implemented 'select' doing a loop, checking for time out and checking the readiness state of the files in the first set. The problem is that there is no way to check readiness in a FileStream in a non-blocking fashion. I thought that 'seek' could be a good approach, but it is blocking, thus not useful for us. Does somebody have a better idea?


** What to do?

The benchmark 186.crafty calls to select with 0s timeout (not blocking, not time out) to test stdin.

We cannot provide this behavior in .NET (or I didn't find the way). In the case that we decide to provide a version for libstd.so only (and may be a warning o an error in MSCorelibWrapper.dll), I think that the better option would be to provide a wrapper for the system 'select' as core function in __host.c. It doesn't take complex structures as inputs, the 'fdset' type is actually an array.

However, my point is to do not implement it at all. Just to modify the Spec2000 benchmark (it already provides platform specific alternatives for the function calling 'select', I think it is fair)

Re: [Gcc4cli-devel] README on how tu build gcc4cli updated

[Andrea C. O. <and...@gm...>]

The binutils should work, they ae written in c#

the problem was in the VMs we had, PVM did not have support for generics

it depends on how you use the CLI-frontend
in libstd itself there should be no problem
you do not have to leave the use of generics in the wrapper
and you should not try to look into MSCorlib.dll

Andrea

On Thu, Feb 17, 2011 at 6:21 PM, Erven Rohou <erv...@in...> wrote:
> Hello,
>
> I vaguely remember that we use mcs (1.0) for a reason.
> It could be that 2.0 starts relying on generics, which are not supported by all
> our tools. Maybe the CLI-frontend?
>
> Will ILJIT handle generics?
>
> If anyone (Andrea? :-) ) has a better recollection, feel free to elaborate.
>
> --
> Erven.
>
>
> Le 17/02/2011 17:51, David Yuste a écrit :
>> I updated the README with the last changes:
>> - Using gmcs instead of mcs
>> - Building and using libstd.so
>>
>> http://gcc.gnu.org/viewcvs/branches/st/README?view=markup
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Gcc4cli-devel mailing list
> Gcc...@li...
> https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel
>

Re: [Gcc4cli-devel] README on how tu build gcc4cli updated

[Erven R. <erv...@in...>]

Hello,

I vaguely remember that we use mcs (1.0) for a reason.
It could be that 2.0 starts relying on generics, which are not supported by all 
our tools. Maybe the CLI-frontend?

Will ILJIT handle generics?

If anyone (Andrea? :-) ) has a better recollection, feel free to elaborate.

--
Erven.


Le 17/02/2011 17:51, David Yuste a écrit :
> I updated the README with the last changes:
> - Using gmcs instead of mcs
> - Building and using libstd.so
>
> http://gcc.gnu.org/viewcvs/branches/st/README?view=markup

[Gcc4cli-devel] README on how tu build gcc4cli updated

[David Y. <dav...@in...>]

I updated the README with the last changes: 
- Using gmcs instead of mcs 
- Building and using libstd.so 

http://gcc.gnu.org/viewcvs/branches/st/README?view=markup 

Re: [Gcc4cli-devel] CLI-BE (rev 170127): more functionality in libstd::stat()

[David Y. <dav...@in...>]

With this patch, MSCorelibWrapper.cs uses the namespace AccessControl. It is implemented in the version 2.0 of the Mono library. 
If you followed the indications of the wiki for building cli-be, you may have configured it to use mcs (version of mono compiler using 1.0 libraries). Now we must switch to gmcs (the version using 2.0 libraries), thus we must reconfigure the compiler exporting MCS as gmcs (I guess that including the flag --with-mcs=gmcs in the configuration line may have the same effect). 
I will try to update the wiki. 

----- Mail original -----


De: "David Yuste" <dav...@in...> 
À: gcc...@li... 
Envoyé: Lundi 14 Février 2011 14:45:52 
Objet: [Gcc4cli-devel] CLI-BE (rev 170127): more functionality in libstd::stat() 


This patch (committed as revision 170127) provides more functionality to libstd::stat. New fields in 'struct stat' have been added. 

New core functions: file_lastaccess_sutc, file_lastwrite_sutc, file_filecreation_sutc, file_mode_flags, 
file_uid, file_gid 

Implementation in MSCorelibWrapper (-> MSCorelibWrapper.dll): 
file_filecreation_sutc() tries to behave as 'struct stat::st_ctime', but it is not exactly the same. 
st_ctime is the time of the last change of status (mode, owner, etc.), while file_filecreation_sutc() 
returns creation time. This difference arises from .NET design. 
file_mode_flags() is only a partial approximation. I did my best with the permits in .NET, but there is 
not a perfect match. 
file_uid() and file_gid() returns 0 

Implementation in __host.c (-> optimized MSCorelibWrapper.dll, libstd.so): 
Each core function uses a call to the host 'stat()' in order to get the requested value 
(may be some kind of caching implementation could improve this) 

Affected benchmarks: 164.gzip 

------------------------------------------------------------------------------ 
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: 
Pinpoint memory and threading errors before they happen. 
Find and fix more than 250 security defects in the development cycle. 
Locate bottlenecks in serial and parallel code that limit performance. 
http://p.sf.net/sfu/intel-dev2devfeb 
_______________________________________________ 
Gcc4cli-devel mailing list 
Gcc...@li... 
https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel 

[Gcc4cli-devel] SPEC2000: 164.gzip works (cil32, gcil and mono)

[David Y. <dav...@in...>]

At cli-be revision 170180, and cli-fe revision 170183, the benchmark compiles (cil32), runs in Mono, compiles back to native (gcil) and runs in native. 

[Gcc4cli-devel] CLI-FE (rev 170183): Libstd linkage in the front end

[David Y. <dav...@in...>]

This patch (committed at revision 170183) modifies the way gcil manages libstd calls. Now, each libstd function name is prefixed with "Libstd_", so that they can be linked with the implementation in libstd.so (for more information about "why this patch", take a look at the thread "Libstd, many doubts" in this mailing list). The ancient behavior of gcil is still supported, continue reading. 

** New flags 

This behavior can be tuned with the following flags: 
-fcil-use-libstd (enabled by default), libstd.so is used. 
-fcil-use-libstd-builtins (enabled by default), also builtins (ie., cos, log, printf, etc.) are translated into libstd.so naming. 

And its complementary: 
-fno-cil-use-libstd-builtins, exclude builtins from translation . 
-fno-cil-use-libstd, don't translate anything at all (the behavior of gcil before this patch). 

I'd like to focus on the flag -fno-cil-use-libstd-builtins. I provided it because I thought that it can be interesting to keep the builtins as builtins (because of performance). But actually, calls such as printf make the final executable crash (probably because of interactions between libstd.so and system implementation). A further work will be to select only those builtins that can be considered safe (maths, for instance, pure constant functions). 


** Briefly, how to use 

The traditional way: libstd calls are just bypassed to the system libraries. Absolutely unsafe, use at your own risk: 
$ gcil -fno-cil-use-libstd <... > 

The new way: linking with libstd.so: 
$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:<gcil-be-base-image>/lib/<ARCHITECTURE>/ 
$ gcil -lstd <...> 


** How to build libstd.so 

This object belongs to the back end. In order to build it (we should incorporate it into the automake system of the back end): 
<cli-be-base>$ mkdir gcc-build/gcc/libstd 
<cli-be-base>$ cd gcc-build/gcc/libstd 
<cli-be-base>$ <cli-be-base>/gcc-src/gcc/libstd/configure --enable-native-lib --with-mcs=gmcs --prefix=<cli-be-base>/image 
<cli-be-base>$ make && make install 

[Gcc4cli-devel] CLI-BE (rev 170127): more functionality in libstd::stat()

[David Y. <dav...@in...>]

This patch (committed as revision 170127) provides more functionality to libstd::stat. New fields in 'struct stat' have been added. 

New core functions: file_lastaccess_sutc, file_lastwrite_sutc, file_filecreation_sutc, file_mode_flags, 
file_uid, file_gid 

Implementation in MSCorelibWrapper (-> MSCorelibWrapper.dll): 
file_filecreation_sutc() tries to behave as 'struct stat::st_ctime', but it is not exactly the same. 
st_ctime is the time of the last change of status (mode, owner, etc.), while file_filecreation_sutc() 
returns creation time. This difference arises from .NET design. 
file_mode_flags() is only a partial approximation. I did my best with the permits in .NET, but there is 
not a perfect match. 
file_uid() and file_gid() returns 0 

Implementation in __host.c (-> optimized MSCorelibWrapper.dll, libstd.so): 
Each core function uses a call to the host 'stat()' in order to get the requested value 
(may be some kind of caching implementation could improve this) 

Affected benchmarks: 164.gzip 

Re: [Gcc4cli-devel] Libstd, many doubts

[Andrea C. O. <and...@gm...>]

Yes, I agree, in your context solution #3 is the best.

The default build is the #1

If you want you can compile also the others configuring manually libstd

to build the native version
.../gcc/libstd/configure --enable-native-lib --with-mcs=gmcs
make
make install prefix=...

to build the optimized version of MscorlibWrapper.dll /.so
.../gcc/libstd/configure --enable-opt-native-lib --with-mcs=gmcs
make
make install prefix=...
the code is in the directory src_opt and is just a header that reuses
the same host file used for the native build: __host.c

Afterward, when you want to use the optimized version of the library,
you just have to set the proper search path for the libraries
it finds the MscorlibWrapper.dll with the external calls instead of
the calls to MSCorLib.dll and the .so binary

Andrea


On Thu, Feb 10, 2011 at 5:10 PM, David Yuste <dav...@in...> wrote:
> Hi Andrea,
>
> I want to ask for your opinion about what I have in mind. Just to introduce it, I expose a summary of the possible configurations regarding libstd:
>
> 1. CIL program -> libstd.dll -> MSCorelibWrapper.dll -> .NET
>  (libstd.dll from libstd/src/*.c, including libstd/include/*.h, via cil32)
>  (MSCorelibWrapper.dll from libstd/src/MSCorelibWrapper.cs, via mcs1)
>
> 2. CIL program -> libstd.dll -> MSCorelibWrapper.dll (optimized) -> MSCorelibWrapper_support.so -> host libc
>  (libstd.dll from libstd/src/*.c, including libstd/include/*.h, via cil32)
>  (MSCorelibWrapper.dll from libstd/src_opt/MSCorelibWrapper.cs, via mcs1)
>  (MSCorelibWrapper_support.so from libstd/src_opt/MSCorelibWrapper_support.c, including libstd/src/__host.c, via gcc)
>
> 4. CIL program --gcil--> native program -> host library
>
> 3. CIL program --gcil--> native program -> libstd.so -> MSCorelibWrapper_support.so -> host libc
>  (libstd.dll from libstd/src/*.c, including libstd/include/*.h, *via gcc*)
>  (MSCorelibWrapper_support.so from libstd/src_opt/MSCorelibWrapper_support.c, including libstd/src/__host.c, via gcc)
>
> Configuration 1 is the usual one when using a VM.
>
> Configuration 2 is the optimized version, possible only if we know that there is a libc implementation in the target machine. We don't need to care about data layout (of structures, etc.) since calls reaching MSCorelibWrapper_support.so are only "the core ones". Only scalars and strings as arguments.
>
> Configuration 4 is the currently existing implementation of gcil. Calls to libstd are just bypassed to the host library. Of course this is broken, since gcc4cil headers doesn't match the host ones. I will not longer support this configuration. May be a good idea is to provide a flag in gcil allowing the bypass, so that the end user decides whether to assume the risk or not (**)
>
> Configuration 3 is my personal choice: I think that we can build libstd.so (which is actually the same libstd.dll -libstd/src/*.c-, but compiled targeting native), and let it call to MSCorelibWrapper_support.so, which will interact with the host libc.
> In this way, a native program compiled with gcil is still portable. The only platform dependent library is MSCorelibWrapper_support.so, but it's implementation relies on a single file: src/__host.c. Also, since we reuse the same code to build libstd.so and libstd.dll, no extra effort is required.
>
> What do you think? And by the way, is it already possible to build libstd.so without modifying anything? I say that because I have the feeling that everything is disposed to that end, but I don't see that the library is build. Also, I didn't find MSCorelibWrapper_support.so anywhere. Any hints to build them? Must I introduce some configuration flags or is it still pending to implement in the Makefiles?
>
> --
> (**) Just now (I still have to think in detail), I think that all the symbols in libstd.so must be prefixed by "Libstd_" (as intended by some definitions of the LIBSTD_LPROTO/LIBSTD_LNAME macros). In this way, there won't be any link conflict between libstd.so and the host libc. Thus, it requires to prefix the libstd symbols emitted by gcil too (otherwise, the host library will be linked).
>
> Thanks,
> David
>
>
> ----- Mail original -----
>> De: "David Yuste" <dav...@in...>
>> À: "Andrea Carlo Ornstein" <and...@gm...>
>> Cc: gcc...@li...
>> Envoyé: Mercredi 9 Février 2011 10:28:01
>> Objet: Re: [Gcc4cli-devel] Libstd, many doubts
>> First of all, thanks for the explanation.
>>
>> Well, actually after reading your mail and examining all the versions
>> of each library, I better understand why we need this "framework".
>> Also, I realize that I was too focused towards the "gcil way" (which
>> is probably the less interesting one).
>>
>> Regarding libstd and some posix headers, you are right, we cannot just
>> take the system ones, since there are many platform specific features.
>> Moreover, after looking at the whole picture, I realize that we don't
>> mess up the headers, we just provide a component that cil32 needs to
>> properly work (in a platform independent way), and a set of libraries
>> for runtime compatibility.
>>
>> I continue with the original way: adapted headers + Libstd.dll + the
>> two MSCorelibWrapper.dll. I think that your mail was clarifying
>> enough, so I think that we won't need the phone call for the moment.
>>
>> Thanks,
>> David
>>
>> ----- Mail original -----
>> > De: "Andrea Carlo Ornstein" <and...@gm...>
>> > À: "David Yuste" <dav...@in...>
>> > Cc: gcc...@li...
>> > Envoyé: Mardi 8 Février 2011 15:43:00
>> > Objet: Re: [Gcc4cli-devel] Libstd, many doubts
>> > The main idea of libstd is to abstract the libc so the compiler can
>> > generate a binary that is independent from how it will be run.
>> > It is implemented in C and compiled with gcc4net.
>> >
>> > The library is an implementation of the standard libc on top of a
>> > set
>> > of primitives that are defined in MSCorelibWrapper.dll
>> >
>> > There are two different implementations of MSCorelibWrapper.dll
>> > the first one is implemented with calls to MSCorelib and so all your
>> > application is CLI, you can run it where you want with any VM
>> > the second one is implemented with calls to the native libc and so
>> > it
>> > is not portable, it does the proper conversions needed on the target
>> > from the standard interface exposed by libstd and the native
>> > implementation, you need one for each target
>> >
>> > So your application always use libstd (that is a valid CLI binary
>> > and
>> > provides the libc) wich uses MSCorelibWrapper.dll (that can be
>> > portable or optimized for a specific target)
>> >
>> > After that when we decided to use CLI as an intermediate
>> > representation we had different choices.
>> > to translate also the libstd from cli to native and keep the binding
>> > to the native target at the MSCorelibWrapper.dll level
>> > or to understand where the libc was starting and, if the layout of
>> > the
>> > implementation of libstd was compatible with the native one, replace
>> > the calls to libstd directly with calls to the target native
>> > libraries.
>> > For lack of time we decided for the second.
>> >
>> > If you want to use another libc implementation, you can do it.
>> > But you have to port it
>> > on what?
>> > Do you target MSCorlib, so it is portable and runs on all VMs?
>> > MScorlib have a lot of high level abstractions but usually the
>> > implementations of libc start from system calls provided from the OS
>> > how do you match the two abstraction levels is not easy.
>> >
>> > If you use it as an intermediate IR instead what we want to do?
>> > Logically I would like to use directly the headers of the target
>> > but this implies that I have to understand all the nuances used in
>> > the
>> > implementation of the headers of that target, at least
>> > if you look at the gnu libc you will see a lot of inline assembly,
>> > attributes target dependent and so on
>> > So we end up having to include in the compiler the interpretation of
>> > a
>> > lot of stuff for each target that we want to support.
>> >
>> > I just wrote it down quickly, but it is best if we hear each other
>> > by
>> > phone.
>> > Andrea
>> >
>> >
>> >
>> > On Mon, Feb 7, 2011 at 3:38 PM, David Yuste <dav...@in...>
>> > wrote:
>> > > Hi all,
>> > >
>> > > In order to support most of the SPEC2000 benchmark, we must
>> > > provide
>> > > many
>> > > libstd and unix/posix headers. I'm about to commit many of them
>> > > into
>> > > the
>> > > cli-be branch, but before I'd like to clarify and discuss some
>> > > concepts
>> > > (because may be we can do something better/easier)
>> > >
>> > > As far as I understood, there are several ways to execute a CIL
>> > > binaries
>> > > produced by cli-be (regarding libstd). For instance, when gcil is
>> > > used,
>> > > calls to libstd are just intercepted (while parsing) and replaced
>> > > with the
>> > > corresponding native call. When Mono or .NET is used, I think that
>> > > the
>> > > versions in MSCorelibWrapper.dll and/or (??) Libstd.dll are
>> > > called.
>> > > However,
>> > > there are many things that I don't really understand:
>> > >
>> > > - What are the .c files in gcc/libstd/src/, when are they used? In
>> > > order to
>> > > build Libstd.dll? (but it is C code!)
>> > > - What do we expect from MSCorelibWrapper.dll and what from
>> > > Libstd.dll? When
>> > > do we use each one?
>> > > - How do the macros in every .h file of gcc/libstd/inluce/ work?
>> > >
>> > > Also, another issue is the following. We do special effort to
>> > > don't
>> > > mess up
>> > > with gcc, thus we put everything in a separate folder, and so
>> > > on...
>> > > but, we
>> > > mess up the whole libstd?? Is not there a better way to do it?
>> > > Also,
>> > > note
>> > > that this issue enforces as to rewrite almost every header in
>> > > order
>> > > to be
>> > > compatible with ordinary programs.
>> > >
>> > > So, in conclusion, my question is about the libstd compatibility
>> > > philosophy,
>> > > details on how does it work, and why it worths to mess up all the
>> > > headers.
>> > >
>> > > Thanks,
>> > > David
>> > >
>> > >
>> > >
>> > > ------------------------------------------------------------------------------
>> > > The modern datacenter depends on network connectivity to access
>> > > resources
>> > > and provide services. The best practices for maximizing a physical
>> > > server's
>> > > connectivity to a physical network are well understood - see how
>> > > these
>> > > rules translate into the virtual world?
>> > > http://p.sf.net/sfu/oracle-sfdevnlfb
>> > > _______________________________________________
>> > > Gcc4cli-devel mailing list
>> > > Gcc...@li...
>> > > https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel
>> > >
>> > >
>>
>> ------------------------------------------------------------------------------
>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio
>> XE:
>> Pinpoint memory and threading errors before they happen.
>> Find and fix more than 250 security defects in the development cycle.
>> Locate bottlenecks in serial and parallel code that limit performance.
>> http://p.sf.net/sfu/intel-dev2devfeb
>> _______________________________________________
>> Gcc4cli-devel mailing list
>> Gcc...@li...
>> https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel
>

Re: [Gcc4cli-devel] Libstd, many doubts

[David Y. <dav...@in...>]

Hi Andrea,

I want to ask for your opinion about what I have in mind. Just to introduce it, I expose a summary of the possible configurations regarding libstd:

1. CIL program -> libstd.dll -> MSCorelibWrapper.dll -> .NET
  (libstd.dll from libstd/src/*.c, including libstd/include/*.h, via cil32)
  (MSCorelibWrapper.dll from libstd/src/MSCorelibWrapper.cs, via mcs1)
  
2. CIL program -> libstd.dll -> MSCorelibWrapper.dll (optimized) -> MSCorelibWrapper_support.so -> host libc
  (libstd.dll from libstd/src/*.c, including libstd/include/*.h, via cil32)
  (MSCorelibWrapper.dll from libstd/src_opt/MSCorelibWrapper.cs, via mcs1)
  (MSCorelibWrapper_support.so from libstd/src_opt/MSCorelibWrapper_support.c, including libstd/src/__host.c, via gcc)

4. CIL program --gcil--> native program -> host library

3. CIL program --gcil--> native program -> libstd.so -> MSCorelibWrapper_support.so -> host libc
  (libstd.dll from libstd/src/*.c, including libstd/include/*.h, *via gcc*)
  (MSCorelibWrapper_support.so from libstd/src_opt/MSCorelibWrapper_support.c, including libstd/src/__host.c, via gcc)

Configuration 1 is the usual one when using a VM.

Configuration 2 is the optimized version, possible only if we know that there is a libc implementation in the target machine. We don't need to care about data layout (of structures, etc.) since calls reaching MSCorelibWrapper_support.so are only "the core ones". Only scalars and strings as arguments.

Configuration 4 is the currently existing implementation of gcil. Calls to libstd are just bypassed to the host library. Of course this is broken, since gcc4cil headers doesn't match the host ones. I will not longer support this configuration. May be a good idea is to provide a flag in gcil allowing the bypass, so that the end user decides whether to assume the risk or not (**)

Configuration 3 is my personal choice: I think that we can build libstd.so (which is actually the same libstd.dll -libstd/src/*.c-, but compiled targeting native), and let it call to MSCorelibWrapper_support.so, which will interact with the host libc.
In this way, a native program compiled with gcil is still portable. The only platform dependent library is MSCorelibWrapper_support.so, but it's implementation relies on a single file: src/__host.c. Also, since we reuse the same code to build libstd.so and libstd.dll, no extra effort is required.

What do you think? And by the way, is it already possible to build libstd.so without modifying anything? I say that because I have the feeling that everything is disposed to that end, but I don't see that the library is build. Also, I didn't find MSCorelibWrapper_support.so anywhere. Any hints to build them? Must I introduce some configuration flags or is it still pending to implement in the Makefiles?

--
(**) Just now (I still have to think in detail), I think that all the symbols in libstd.so must be prefixed by "Libstd_" (as intended by some definitions of the LIBSTD_LPROTO/LIBSTD_LNAME macros). In this way, there won't be any link conflict between libstd.so and the host libc. Thus, it requires to prefix the libstd symbols emitted by gcil too (otherwise, the host library will be linked).

Thanks,
David


----- Mail original -----
> De: "David Yuste" <dav...@in...>
> À: "Andrea Carlo Ornstein" <and...@gm...>
> Cc: gcc...@li...
> Envoyé: Mercredi 9 Février 2011 10:28:01
> Objet: Re: [Gcc4cli-devel] Libstd, many doubts
> First of all, thanks for the explanation.
> 
> Well, actually after reading your mail and examining all the versions
> of each library, I better understand why we need this "framework".
> Also, I realize that I was too focused towards the "gcil way" (which
> is probably the less interesting one).
> 
> Regarding libstd and some posix headers, you are right, we cannot just
> take the system ones, since there are many platform specific features.
> Moreover, after looking at the whole picture, I realize that we don't
> mess up the headers, we just provide a component that cil32 needs to
> properly work (in a platform independent way), and a set of libraries
> for runtime compatibility.
> 
> I continue with the original way: adapted headers + Libstd.dll + the
> two MSCorelibWrapper.dll. I think that your mail was clarifying
> enough, so I think that we won't need the phone call for the moment.
> 
> Thanks,
> David
> 
> ----- Mail original -----
> > De: "Andrea Carlo Ornstein" <and...@gm...>
> > À: "David Yuste" <dav...@in...>
> > Cc: gcc...@li...
> > Envoyé: Mardi 8 Février 2011 15:43:00
> > Objet: Re: [Gcc4cli-devel] Libstd, many doubts
> > The main idea of libstd is to abstract the libc so the compiler can
> > generate a binary that is independent from how it will be run.
> > It is implemented in C and compiled with gcc4net.
> >
> > The library is an implementation of the standard libc on top of a
> > set
> > of primitives that are defined in MSCorelibWrapper.dll
> >
> > There are two different implementations of MSCorelibWrapper.dll
> > the first one is implemented with calls to MSCorelib and so all your
> > application is CLI, you can run it where you want with any VM
> > the second one is implemented with calls to the native libc and so
> > it
> > is not portable, it does the proper conversions needed on the target
> > from the standard interface exposed by libstd and the native
> > implementation, you need one for each target
> >
> > So your application always use libstd (that is a valid CLI binary
> > and
> > provides the libc) wich uses MSCorelibWrapper.dll (that can be
> > portable or optimized for a specific target)
> >
> > After that when we decided to use CLI as an intermediate
> > representation we had different choices.
> > to translate also the libstd from cli to native and keep the binding
> > to the native target at the MSCorelibWrapper.dll level
> > or to understand where the libc was starting and, if the layout of
> > the
> > implementation of libstd was compatible with the native one, replace
> > the calls to libstd directly with calls to the target native
> > libraries.
> > For lack of time we decided for the second.
> >
> > If you want to use another libc implementation, you can do it.
> > But you have to port it
> > on what?
> > Do you target MSCorlib, so it is portable and runs on all VMs?
> > MScorlib have a lot of high level abstractions but usually the
> > implementations of libc start from system calls provided from the OS
> > how do you match the two abstraction levels is not easy.
> >
> > If you use it as an intermediate IR instead what we want to do?
> > Logically I would like to use directly the headers of the target
> > but this implies that I have to understand all the nuances used in
> > the
> > implementation of the headers of that target, at least
> > if you look at the gnu libc you will see a lot of inline assembly,
> > attributes target dependent and so on
> > So we end up having to include in the compiler the interpretation of
> > a
> > lot of stuff for each target that we want to support.
> >
> > I just wrote it down quickly, but it is best if we hear each other
> > by
> > phone.
> > Andrea
> >
> >
> >
> > On Mon, Feb 7, 2011 at 3:38 PM, David Yuste <dav...@in...>
> > wrote:
> > > Hi all,
> > >
> > > In order to support most of the SPEC2000 benchmark, we must
> > > provide
> > > many
> > > libstd and unix/posix headers. I'm about to commit many of them
> > > into
> > > the
> > > cli-be branch, but before I'd like to clarify and discuss some
> > > concepts
> > > (because may be we can do something better/easier)
> > >
> > > As far as I understood, there are several ways to execute a CIL
> > > binaries
> > > produced by cli-be (regarding libstd). For instance, when gcil is
> > > used,
> > > calls to libstd are just intercepted (while parsing) and replaced
> > > with the
> > > corresponding native call. When Mono or .NET is used, I think that
> > > the
> > > versions in MSCorelibWrapper.dll and/or (??) Libstd.dll are
> > > called.
> > > However,
> > > there are many things that I don't really understand:
> > >
> > > - What are the .c files in gcc/libstd/src/, when are they used? In
> > > order to
> > > build Libstd.dll? (but it is C code!)
> > > - What do we expect from MSCorelibWrapper.dll and what from
> > > Libstd.dll? When
> > > do we use each one?
> > > - How do the macros in every .h file of gcc/libstd/inluce/ work?
> > >
> > > Also, another issue is the following. We do special effort to
> > > don't
> > > mess up
> > > with gcc, thus we put everything in a separate folder, and so
> > > on...
> > > but, we
> > > mess up the whole libstd?? Is not there a better way to do it?
> > > Also,
> > > note
> > > that this issue enforces as to rewrite almost every header in
> > > order
> > > to be
> > > compatible with ordinary programs.
> > >
> > > So, in conclusion, my question is about the libstd compatibility
> > > philosophy,
> > > details on how does it work, and why it worths to mess up all the
> > > headers.
> > >
> > > Thanks,
> > > David
> > >
> > >
> > >
> > > ------------------------------------------------------------------------------
> > > The modern datacenter depends on network connectivity to access
> > > resources
> > > and provide services. The best practices for maximizing a physical
> > > server's
> > > connectivity to a physical network are well understood - see how
> > > these
> > > rules translate into the virtual world?
> > > http://p.sf.net/sfu/oracle-sfdevnlfb
> > > _______________________________________________
> > > Gcc4cli-devel mailing list
> > > Gcc...@li...
> > > https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel
> > >
> > >
> 
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio
> XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Gcc4cli-devel mailing list
> Gcc...@li...
> https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel

Re: [Gcc4cli-devel] Libstd, many doubts

[David Y. <dav...@in...>]

First of all, thanks for the explanation.

Well, actually after reading your mail and examining all the versions of each library, I better understand why we need this "framework". Also, I realize that I was too focused towards the "gcil way" (which is probably the less interesting one).

Regarding libstd and some posix headers, you are right, we cannot just take the system ones, since there are many platform specific features. Moreover, after looking at the whole picture, I realize that we don't mess up the headers, we just provide a component that cil32 needs to properly work (in a platform independent way), and a set of libraries for runtime compatibility. 

I continue with the original way: adapted headers + Libstd.dll + the two MSCorelibWrapper.dll. I think that your mail was clarifying enough, so I think that we won't need the phone call for the moment.

Thanks,
David

----- Mail original -----
> De: "Andrea Carlo Ornstein" <and...@gm...>
> À: "David Yuste" <dav...@in...>
> Cc: gcc...@li...
> Envoyé: Mardi 8 Février 2011 15:43:00
> Objet: Re: [Gcc4cli-devel] Libstd, many doubts
> The main idea of libstd is to abstract the libc so the compiler can
> generate a binary that is independent from how it will be run.
> It is implemented in C and compiled with gcc4net.
> 
> The library is an implementation of the standard libc on top of a set
> of primitives that are defined in MSCorelibWrapper.dll
> 
> There are two different implementations of MSCorelibWrapper.dll
> the first one is implemented with calls to MSCorelib and so all your
> application is CLI, you can run it where you want with any VM
> the second one is implemented with calls to the native libc and so it
> is not portable, it does the proper conversions needed on the target
> from the standard interface exposed by libstd and the native
> implementation, you need one for each target
> 
> So your application always use libstd (that is a valid CLI binary and
> provides the libc) wich uses MSCorelibWrapper.dll (that can be
> portable or optimized for a specific target)
> 
> After that when we decided to use CLI as an intermediate
> representation we had different choices.
> to translate also the libstd from cli to native and keep the binding
> to the native target at the MSCorelibWrapper.dll level
> or to understand where the libc was starting and, if the layout of the
> implementation of libstd was compatible with the native one, replace
> the calls to libstd directly with calls to the target native
> libraries.
> For lack of time we decided for the second.
> 
> If you want to use another libc implementation, you can do it.
> But you have to port it
> on what?
> Do you target MSCorlib, so it is portable and runs on all VMs?
> MScorlib have a lot of high level abstractions but usually the
> implementations of libc start from system calls provided from the OS
> how do you match the two abstraction levels is not easy.
> 
> If you use it as an intermediate IR instead what we want to do?
> Logically I would like to use directly the headers of the target
> but this implies that I have to understand all the nuances used in the
> implementation of the headers of that target, at least
> if you look at the gnu libc you will see a lot of inline assembly,
> attributes target dependent and so on
> So we end up having to include in the compiler the interpretation of a
> lot of stuff for each target that we want to support.
> 
> I just wrote it down quickly, but it is best if we hear each other by
> phone.
> Andrea
> 
> 
> 
> On Mon, Feb 7, 2011 at 3:38 PM, David Yuste <dav...@in...>
> wrote:
> > Hi all,
> >
> > In order to support most of the SPEC2000 benchmark, we must provide
> > many
> > libstd and unix/posix headers. I'm about to commit many of them into
> > the
> > cli-be branch, but before I'd like to clarify and discuss some
> > concepts
> > (because may be we can do something better/easier)
> >
> > As far as I understood, there are several ways to execute a CIL
> > binaries
> > produced by cli-be (regarding libstd). For instance, when gcil is
> > used,
> > calls to libstd are just intercepted (while parsing) and replaced
> > with the
> > corresponding native call. When Mono or .NET is used, I think that
> > the
> > versions in MSCorelibWrapper.dll and/or (??) Libstd.dll are called.
> > However,
> > there are many things that I don't really understand:
> >
> > - What are the .c files in gcc/libstd/src/, when are they used? In
> > order to
> > build Libstd.dll? (but it is C code!)
> > - What do we expect from MSCorelibWrapper.dll and what from
> > Libstd.dll? When
> > do we use each one?
> > - How do the macros in every .h file of gcc/libstd/inluce/ work?
> >
> > Also, another issue is the following. We do special effort to don't
> > mess up
> > with gcc, thus we put everything in a separate folder, and so on...
> > but, we
> > mess up the whole libstd?? Is not there a better way to do it? Also,
> > note
> > that this issue enforces as to rewrite almost every header in order
> > to be
> > compatible with ordinary programs.
> >
> > So, in conclusion, my question is about the libstd compatibility
> > philosophy,
> > details on how does it work, and why it worths to mess up all the
> > headers.
> >
> > Thanks,
> > David
> >
> >
> >
> > ------------------------------------------------------------------------------
> > The modern datacenter depends on network connectivity to access
> > resources
> > and provide services. The best practices for maximizing a physical
> > server's
> > connectivity to a physical network are well understood - see how
> > these
> > rules translate into the virtual world?
> > http://p.sf.net/sfu/oracle-sfdevnlfb
> > _______________________________________________
> > Gcc4cli-devel mailing list
> > Gcc...@li...
> > https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel
> >
> >

Re: [Gcc4cli-devel] Libstd, many doubts

[Andrea C. O. <and...@gm...>]

The main idea of libstd is to abstract the libc so the compiler can
generate a binary that is independent from how it will be run.
It is implemented in C and compiled with gcc4net.

The library is an implementation of the standard libc on top of a set
of primitives that are defined in MSCorelibWrapper.dll

There are two different implementations of MSCorelibWrapper.dll
the first one is implemented with calls to MSCorelib and so all your
application is CLI, you can run it where you want with any VM
the second one is implemented with calls to the native libc and so it
is not portable, it does the proper conversions needed on the target
from the standard interface exposed by libstd and the native
implementation, you need one for each target

So your application always use libstd (that is a valid CLI binary and
provides the libc) wich uses MSCorelibWrapper.dll (that can be
portable or optimized for a specific target)

After that when we decided to use CLI as an intermediate
representation we had different choices.
to translate also the libstd from cli to native and keep the binding
to the native target at the MSCorelibWrapper.dll level
or to understand where the libc was starting and, if the layout of the
implementation of libstd was compatible with the native one, replace
the calls to libstd directly with calls to the target native
libraries.
For lack of time we decided for the second.

If you want to use another libc implementation, you can do it.
But you have to port it
on what?
Do you target MSCorlib, so it is portable and runs on all VMs?
MScorlib have a lot of high level abstractions but usually the
implementations of libc start from system calls provided from the OS
how do you match the two abstraction levels is not easy.

If you use it as an intermediate IR instead what we want to do?
Logically I would like to use directly the headers of the target
but this implies that I have to understand all the nuances used in the
implementation of the headers of that target, at least
if you look at the gnu libc you will see a lot of inline assembly,
attributes target dependent and so on
So we end up having to include in the compiler the interpretation of a
lot of stuff for each target that we want to support.

I just wrote it down quickly, but it is best if we hear each other by phone.
Andrea



On Mon, Feb 7, 2011 at 3:38 PM, David Yuste <dav...@in...> wrote:
> Hi all,
>
> In order to support most of the SPEC2000 benchmark, we must provide many
> libstd and unix/posix headers. I'm about to commit many of them into the
> cli-be branch, but before I'd like to clarify and  discuss some concepts
> (because may be we can do something better/easier)
>
> As far as I understood, there are several ways to execute a CIL binaries
> produced by cli-be (regarding libstd). For instance, when gcil is used,
> calls to libstd are just intercepted (while parsing) and replaced with the
> corresponding native call. When Mono or .NET is used, I think that the
> versions in MSCorelibWrapper.dll and/or (??) Libstd.dll are called. However,
> there are many things that I don't really understand:
>
> - What are the .c files in gcc/libstd/src/, when are they used? In order to
> build Libstd.dll? (but it is C code!)
> - What do we expect from MSCorelibWrapper.dll and what from Libstd.dll? When
> do we use each one?
> - How do the macros in every .h file of gcc/libstd/inluce/ work?
>
> Also, another issue is the following. We do special effort to don't mess up
> with gcc, thus we put everything in a separate folder, and so on... but, we
> mess up the whole libstd?? Is not there a better way to do it? Also, note
> that this issue enforces as to rewrite almost every header in order to be
> compatible with ordinary programs.
>
> So, in conclusion, my question is about the libstd compatibility philosophy,
> details on how does it work, and why it worths to mess up all the headers.
>
> Thanks,
> David
>
>
>
> ------------------------------------------------------------------------------
> The modern datacenter depends on network connectivity to access resources
> and provide services. The best practices for maximizing a physical server's
> connectivity to a physical network are well understood - see how these
> rules translate into the virtual world?
> http://p.sf.net/sfu/oracle-sfdevnlfb
> _______________________________________________
> Gcc4cli-devel mailing list
> Gcc...@li...
> https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel
>
>

[Gcc4cli-devel] Libstd, many doubts

[David Y. <dav...@in...>]

Hi all, 

In order to support most of the SPEC2000 benchmark, we must provide many libstd and unix/posix headers. I'm about to commit many of them into the cli-be branch, but before I'd like to clarify and discuss some concepts (because may be we can do something better/easier) 

As far as I understood, there are several ways to execute a CIL binaries produced by cli-be (regarding libstd). For instance, when gcil is used, calls to libstd are just intercepted (while parsing) and replaced with the corresponding native call. When Mono or .NET is used, I think that the versions in MSCorelibWrapper.dll and/or (??) Libstd.dll are called. However, there are many things that I don't really understand: 

- What are the .c files in gcc/libstd/src/, when are they used? In order to build Libstd.dll? (but it is C code!) 
- What do we expect from MSCorelibWrapper.dll and what from Libstd.dll? When do we use each one? 
- How do the macros in every .h file of gcc/libstd/inluce/ work? 

Also, another issue is the following. We do special effort to don't mess up with gcc, thus we put everything in a separate folder, and so on... but, we mess up the whole libstd?? Is not there a better way to do it? Also, note that this issue enforces as to rewrite almost every header in order to be compatible with ordinary programs. 

So, in conclusion, my question is about the libstd compatibility philosophy, details on how does it work, and why it worths to mess up all the headers. 

Thanks, 
David 

[Gcc4cli-devel] CLI-FE (rev 169829): implemented STIND.I8 and LDIND.I8 in gcc/cil/parser.c

[David Y. <dav...@in...>]

This patch adds support to STIND.I8 and LDIND.I8 in cli-fe, gcc/cil/parser.c 

Affected benchmarks: 186.crafty 

[Gcc4cli-devel] CLI-FE (rev 169791): fixed bug in gcc/cil/parser.c::parser_emit_ldsflda()

[David Y. <dav...@in...>]

Fixed "FIXME" in cli-fe:gcc/cil/parser.c::parser_emit_ldsflda(). Previous implementation didn't take care about static fields, which are unmanaged. Taken the address of an static field must return a CIL_STYPE_NINT address, instead of an CIL_STYPE_MP one. 

Affected benchmarks: 
197.parser, producing the following gcil compilation error: "cil1: error: 3 Wrong operand types for ceq: 

[Gcc4cli-devel] CLI-FE (rev 169791): fixed bug in gcc/cil/parser.c::paser_emit_switch()

[David Y. <dav...@in...>]

CIL parser translates the CIL switch as a SWITCH_EXPR, with NULL SWITCH_BODY, and the labels in SWITCH_LABELS. It seems to be a correct configuration, but gimplifier does nothing with it, the whole switch is ignored (so removed from gimple), thus the resulting code is incorrect. 
It is fixed by the patch gcc-fe.parser_emit_switch.patch (revision 169791). The function gcc/cil/parser.c::paser_emit_switch() is modified. The new version emits a nest of if-then-else instead of a switch. 
Probably it can be improved by means of a sort of switch that gimplifier can handle. 

Affected SPEC2000 benchmarks: 175.vpr and 175.vpr 

[Gcc4cli-devel] SPEC2000: Patch for 175.vpr

[David Y. <dav...@in...>]

Two problems are found for building this benchmark: 

1) A conflict with the definition of "enum stat" defined in pr.h 
Fixed in the patch 175.vpr.patch attached (it is based in a local git repository, but it can be modified without problems). 
Remeber to use the flag -DGCC4CLI when compiling, otherwise the path won't have any effect. 

2) A runtime error. The executable produced by gcil fails with the message "Error in comp_width: Unknown channel type 0" 
The gimple representation of place.c:comp_width() shows that whole switch body is dropped. Fixed in the revision cli-fe:169791 

Re: [Gcc4cli-devel] gettimeofday

[Erven R. <erv...@in...>]

I do not have any definite answer.
But time_t has a wiki page!!!   http://en.wikipedia.org/wiki/Time_t

The standard does not specify the type. Instead there is:
double difftime(time_t time1, time_t time0);

Excerpt from the man:
        On  a  POSIX  system,  time_t is an arithmetic type, and one could just
        define
               #define difftime(t1,t0) (double)(t1 - t0)
        when the possible overflow in the subtraction is  not  a  concern.   On
                 ^^^^^^^^^^^^^^^^^^
        other systems, the data type time_t might use some other encoding where
        subtraction doesn't work directly.



My understanding is that it is not safe to rely on the signedness of time_t.
But we probably increase our level our bug-compatibility if we use the same as 
GNU lib C.

My only concern: is this going to break anything else?

Thoughts?

--
Erven.


Kevin Williams a écrit :
> Hi all,
> 
> I have noticed that gcc4cli declares time_t as an 'unsigned long'.
> The GNU C lib declares it as 'signed long'.
> 
> This difference causes getimeofday to report incorrect numbers when
> using the common function.....
> 
> double time = (endTime.tv_sec - startTime.tv_sec) + ( (endTime.tv_usec
> - startTime.tv_usec) / 1.e6);
> 
> 
> was time_t declared as unsigned long for a reason?
> If not can we change it to signed?
> 
> Thanks,
> Kevin

[Gcc4cli-devel] gettimeofday

[Kevin W. <kev...@in...>]

Hi all,

I have noticed that gcc4cli declares time_t as an 'unsigned long'.
The GNU C lib declares it as 'signed long'.

This difference causes getimeofday to report incorrect numbers when
using the common function.....

double time = (endTime.tv_sec - startTime.tv_sec) + ( (endTime.tv_usec
- startTime.tv_usec) / 1.e6);


was time_t declared as unsigned long for a reason?
If not can we change it to signed?

Thanks,
Kevin

Re: [Gcc4cli-devel] Porting standard libraries

[Erven R. <erv...@in...>]

I think you are correct.

For the struct issue: the CLI back-end chooses a layout. I think we use natural 
alignment of the fields. For most cases, we are probably ok.
In case of less usual fields types, I am not sure what happens.

I do not think we have a way to make sure that the layout seen by the CLI 
back-end matches the layout on any other machine...

--
Erven.



dav...@in... a écrit :
> Hi,
> 
>   I am starting with the port of some standard libraries required by
> Bencspec 2000, and there are several doubts that I would like the
> discuss here. First of all, let me describe the overall architecture of
> the process -as I guess it is, correct me if I'm wrong-, following that
> example:
> 
>  Porting the function fstat() of sys/stat.h
> 
> 1. GCCCIL Back End:
> 
>  in gcc/libstd/src/stat.h, the prototype for the function is defined using
> the LIBSTD_LPROTO macro.
> 
>  in gcc/libstd/src/stat.c, the wrapper for the function is implemented
> using the LIBSTD_LPROTO_IMPL macro. This may contain calls to the
> MsCorelibWrapper library (interaction with the Mono or .NET envrionment)
> 
>  in gcc/libstd/src/MsCorelibWrapper.cs new functions can be implemented if
> more interaction with the Mono or .NET environment is required
> 
>  As result, libstat.dll contains the implementation of our new wrapper.
> When compiling with our Back End, any call to 'fstat()' will be emited as
> a call to our wrapper (something that looks like 'std::fstat...')
> 
> 2.a Runing our CIL program with mono/.NET
>   The runtime environment will call to our wrapper function in the
> corresponding DLL, that will interact with MsCorelibWrapper.dll.
> 
> 2.b GCCIL Front End:
> 
>   In the pass from CIL to native, instead of using any wrapper, calls
> following the format "[std|crt|gcc4net|...]::<function>" are replaced
> with the corresponding library call "<function>". Thanks to that, CIL
> can be used as a general IR without adding extra overhead or modifying
> the semantics of the program (regarding calls to known libraries).
> 
> ---
> 
> So, under the assumption that the previous architecture is the actual one,
> I have several questions regarding the flow 1 -> 2.b (BE + FE):
> 
> * Some library calls take structs as arguments. After the BE compilation
> (C to CIL), these structs are encoded in the CIL representation. After the
> FE compilation (CIL to native), will their layout match the one that the
> library expects (the one produced by the native compiler)?
> 
> * And now, under the assumption that we can trust in our cross-CIL-native
> layout, I guess that each struct defined in one of the gcc/libstd/include/
> files must match (or be layout-compatible) the target system one. Is it
> right?
> For instance, current implementation of "struct stat" only contains one
> field. If we compile with the BE some program calling to 'fstat', and
> later we compile the resulting CIL with the FE, we may get a corrupt code,
> because we actually call to the system 'fstat' function, but the layout of
> the arguments differs to the expected one.
> 
> ---
> 
> Wow, I did a weighty mail! I just want to be sure that I understood the
> actual architecture of gcc4cil.
> 
> Thanks,
> David

[Gcc4cli-devel] Porting standard libraries

[<dav...@in...>]

Hi,

  I am starting with the port of some standard libraries required by
Bencspec 2000, and there are several doubts that I would like the
discuss here. First of all, let me describe the overall architecture of
the process -as I guess it is, correct me if I'm wrong-, following that
example:

 Porting the function fstat() of sys/stat.h

1. GCCCIL Back End:

 in gcc/libstd/src/stat.h, the prototype for the function is defined using
the LIBSTD_LPROTO macro.

 in gcc/libstd/src/stat.c, the wrapper for the function is implemented
using the LIBSTD_LPROTO_IMPL macro. This may contain calls to the
MsCorelibWrapper library (interaction with the Mono or .NET envrionment)

 in gcc/libstd/src/MsCorelibWrapper.cs new functions can be implemented if
more interaction with the Mono or .NET environment is required

 As result, libstat.dll contains the implementation of our new wrapper.
When compiling with our Back End, any call to 'fstat()' will be emited as
a call to our wrapper (something that looks like 'std::fstat...')

2.a Runing our CIL program with mono/.NET
  The runtime environment will call to our wrapper function in the
corresponding DLL, that will interact with MsCorelibWrapper.dll.

2.b GCCIL Front End:

  In the pass from CIL to native, instead of using any wrapper, calls
following the format "[std|crt|gcc4net|...]::<function>" are replaced
with the corresponding library call "<function>". Thanks to that, CIL
can be used as a general IR without adding extra overhead or modifying
the semantics of the program (regarding calls to known libraries).

---

So, under the assumption that the previous architecture is the actual one,
I have several questions regarding the flow 1 -> 2.b (BE + FE):

* Some library calls take structs as arguments. After the BE compilation
(C to CIL), these structs are encoded in the CIL representation. After the
FE compilation (CIL to native), will their layout match the one that the
library expects (the one produced by the native compiler)?

* And now, under the assumption that we can trust in our cross-CIL-native
layout, I guess that each struct defined in one of the gcc/libstd/include/
files must match (or be layout-compatible) the target system one. Is it
right?
For instance, current implementation of "struct stat" only contains one
field. If we compile with the BE some program calling to 'fstat', and
later we compile the resulting CIL with the FE, we may get a corrupt code,
because we actually call to the system 'fstat' function, but the layout of
the arguments differs to the expected one.

---

Wow, I did a weighty mail! I just want to be sure that I understood the
actual architecture of gcc4cil.

Thanks,
David

Re: [Gcc4cli-devel] Printing and debugging patch

[Andrea C. O. <and...@gm...>]

Bienvenido a la mailing list :)

I checked the patch and it seems ok for me.

Andrea

On Wed, Jun 9, 2010 at 10:21 AM,  <dav...@in...> wrote:
> Hi,
>
>  This is my first post here, I am David Yuste and I am going to work on
> gcc4cli at Irisa's Alf group.
>
>  I did a patch to get the CIL trees printed when compiling with
> -fdump-tree-all, and also to be able to print the tree when debugging.
>
>  It introduces the properties PROP_cil, which is provided by the pass
> gimple2cil and, now, it is required by all the subsequent cil-passes.
>
>  At debug time you can use the functions defined at
> gcc/gcc/config/cil32/cil-dump.c (I modified the names to make it cil
> specific, without introducing confusion):
>
>  void dump_cil_function_to_file (tree fn, FILE *file, int flags);
>
>  void dump_cil_stmt (FILE * file, const_cil_stmt stmt, cil_stack stack);
>  void dump_cil_label_name (FILE *, const_tree);
>  void dump_cil_decl_name (FILE *, const_tree);
>  void dump_cil_valuetype_name (FILE *, const_tree);
>  void dump_cil_fun_signature (FILE *, const_tree);
>  void dump_cil_type (FILE *, const_tree type);
>
>  The path modifies passes.c and tree-pass.h (in addition to some cil files)
>
>  Regards
>  David Yuste
>
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Gcc4cli-devel mailing list
> Gcc...@li...
> https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel
>
>

[Gcc4cli-devel] Printing and debugging patch

[<dav...@in...>]

Hi,

  This is my first post here, I am David Yuste and I am going to work on
gcc4cli at Irisa's Alf group.

  I did a patch to get the CIL trees printed when compiling with
-fdump-tree-all, and also to be able to print the tree when debugging.

  It introduces the properties PROP_cil, which is provided by the pass
gimple2cil and, now, it is required by all the subsequent cil-passes.

  At debug time you can use the functions defined at
gcc/gcc/config/cil32/cil-dump.c (I modified the names to make it cil
specific, without introducing confusion):

  void dump_cil_function_to_file (tree fn, FILE *file, int flags);

  void dump_cil_stmt (FILE * file, const_cil_stmt stmt, cil_stack stack);
  void dump_cil_label_name (FILE *, const_tree);
  void dump_cil_decl_name (FILE *, const_tree);
  void dump_cil_valuetype_name (FILE *, const_tree);
  void dump_cil_fun_signature (FILE *, const_tree);
  void dump_cil_type (FILE *, const_tree type);

  The path modifies passes.c and tree-pass.h (in addition to some cil files)

  Regards
  David Yuste