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
>
>