[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