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
|
