sortie wrote:Hi, I finally had a chance to read through your draft article. I realize it's not finished, but I figured I'd comment anyway. I don't have that much time right now, but I'll try to get some points across and continue later.
The C standard doesn't mandate any calling conventions. It's all entirely implementation defined. C could in theory be interpreted rather than translated. When you hear of the 'C calling convention', it refers to some default standard calling convention that everybody happened to agree upon (at least in the i386) world - it's called this because Windows has a heap of other calling conventions and the 'C calling convention' happens to the default and it's rather simple.
there are still calling convention that are recognized by many if not all compilers, like __cdecl, __stdcall, __fastcall, and the cpu also has standard way to make calls
sortie wrote:
Note that libgcc is part of GCC, it doesn't have anything to do with GNU/Linux. There is a libgcc on Windows as well.
well gcc is the compiler used to build gnu linux, and shipped with it as well, the libc used in linux system is also the one of gcc, so they are still tightly related to each other
sortie wrote:
You appear to be confused about the relationship between a compiler and the libc. You appear to have a Windows background, where the official compiler suite is Visual Studio where they ship a libc and compiler together, they are tightly coupled there. You suggest furthermore that programs should ship with their own copy of the libc as a shared library. This is really, really stupid. It's how Windows work, sure, but the C library is meant to be just another core system library. There is a completely staggering excess of code duplication in Windows - this is largely attributed to that programs can't assume anything is installed and sharing shared libraries is out of the question because few people care about binary compatibility.
i don't have only a window background, i programmed on both windows and linux, and i issue the two different configurations, the goal is to be able to have C code that can be compiled both under windows and linux, with any compiler, and used in the same over all project.
sortie wrote: My point is that the compiler and libc are separate projects and there is no such thing as a "compiler libc" universally (although, some systems do use this botched scheme).
all big compilers use their own version of the C library, including gcc and visual studio, and most other C compilers. actually i don't think there is a even a single implementation of the C library that can be called a standard implementation that would work with every executable compiled with any compiler. this just doesn't exist. and most if not all major implementation of C library are shipped with a compiler and specific to it.
sortie wrote:
You don't appear to understand cross-compilation and why it's so vitally important for osdev work. Note that the 'build' platform is the one where the compiler runs, and the 'host' platform is where the program will run, and the target platform is what kind of machine code the program emits (if the program is a compiler, otherwise irrelevant). Your compiler must use the headers of the host platform libc and the host platform libc itself when linking. You cannot use the headers of your build platform and link with the host platform libc. Your little charade of prefixing everything with os_ is just working around that your compiler is using the wrong headers by default. Your compiler should never even consider using the wrong headers. A cross-compiler knows it doesn't target the build platform, so there never is any risk of using the wrong headers or libraries. If your OS has a libc, I strongly recommend setting up a 'OS Specific Toolchain' (see wiki article) which means you modify gcc to make it know about your OS and its libc.
the tricks are just to avoid problems, and to get rid of using any header that a compiler 'should include', but here you just contradict yourself when you say a compiler should never consider using the wrong header, and saying the lib C is totally independent of the compiler, maybe in theory that's supposed to be the case, but it's not how it works in most case.
this system is specially to avoid to use any 'wrong header' , because it doesn't use any header of any C library, and so the compiler always know what to do and how to declare and use the functions, that's the whole point of the system, that you can have a program compiled with visual studio and a program compiled with gcc that doesn't require to have the two version of the libc installed to run depending on which header it included and which compiler it has been compiled with
basically it get rid of many of the 'host' vs 'target' problem, at least for the problems specific to the use of C library and runtime, because it doesn't use the host C library header nor the host C library at all. so the build is made independent on the host for everything related to the C library, and the executable produced will be compatible no matter what host it is compiled on, and which compiler is used to compile it, it's the point of doing this
linux can have many advantages, but linux doesn't provide binary compatibility between distribution or versions, even a little variation in version of library and the program can't run, and it's a serious disadvantage for development of commercial non open source applications.
with this system, any compiler can be used to create the executable file on any type of host, because it doesn't use anything on the host system or the C library header and implementation specific to the 'host' building environment
if people want to develop application in C under windows with visual studio, borland , code warrior, or other compiler, with this system they can without problem, or use any gcc they have installed on the host to compile the file, but using definition of C functions from headers that are not the one present 'by default' on the host, and not the one that the compiler use by default that are either from the host system or from the local building environment, but instead use custom declarations of the functions that are compatible with every compilers but independent from the host configuration or specific building environment
provided that the compiler can generate valid machine code for the target architecture, and can respect calling convention specified explicitly in the host/compiler independent headers, with this system the host platform doesn't matter at all, neither even the compiler normally
i tend to make difference already between 'host system' and 'building environment', because even without having cross compiler, the same host can run different compilers with each their own version of the C headers and C library that are not entirely compatible with each other, or different compiler can be configured as well on the same host to compile different applications without it to be cross compiling for another target as well, it's the case with the linux version of the intel compiler for example. and much more common under windows.
with this system, any compiler from any host can generate the executable in a manner compatible with the target, without needing a cross compiler
