From: David Y. <dav...@in...> - 2011-02-07 14:39:03
|
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 |