Menu
▾
▴
Re: [Gcc4cli-devel] Libstd, many doubts
|
From: Andrea C. O. <and...@gm...> - 2011-02-11 13:42:51
|
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 > |
