3

I have been doing a lot reading lately about how glibc functions wrap system calls in linux. I am wondering however about the relationship between glibc and the GNU C Compiler.
Lets say for example I wanted to write my own C Standard implementation and write a new library called "newglibc" and I change things just slightly. Like for example I take more checks and actions before and after the system calls. Would I have to write a new compiler? Or would I be able to use the same GNU gcc compiler?

If the compiler is completely separate from the library, then would someone be able to, THEORETICALLY, use the gcc on windows system if they could turn it into a .exe and provide the standard C library that windows provides?
Thank you

  • 2
    You can use the same compiler. There is a switch `-nostdlib` to turn off default linking to glibc. There are multiple different standard library implementations available already and used in production – M.M May 22 '18 at 03:46
  • 2
    Glibc is much more than a "standard C library". As you mention, it also handles "system calls", which are functions not part of the C standard. Also, some parts of the C standard library is not in glibc but in a GCC-specific library. – Some programmer dude May 22 '18 at 03:46
  • 2
    Your second question is unclear, there are already ports of gcc to windows (which don't use glibc, since the glibc developers do not wish to support windows) – M.M May 22 '18 at 03:47
  • @M.M Are you referring to cygwin by any chance? –  May 22 '18 at 03:57
  • 1
    Or MinGW. And there are probably other ports. – Some programmer dude May 22 '18 at 04:05
  • @hescobar Not specifically – M.M May 22 '18 at 04:14
  • I am told that replacing RTL functions with your own implementation is UB. You certainly have to be careful, see [this thread](https://stackoverflow.com/questions/49714284/what-is-strlen-elision/49714335#49714335). – Paul Sanders May 22 '18 at 05:18

1 Answers1

5

The Linux kernel, the GNU C Library ("glibc"), and the GNU Compiler Collection (gcc) are three separate development projects. They are often used all together, but they don't have to be. The ones with "GNU" in their name are offically part of the GNU Project; Linux isn't.

The C standard does not make a distinction between the "compiler" and the "library"; it's all one "implementation" to the committee. It is largely a historical accident that GCC is a separate development project from glibc—but a motivated one: back in the day, each commercial Unix variant shipped with its own C library and compiler, and they were terrible, 90% bugs by volume was typical. GNU got its start providing a less terrible replacement for the compiler (and the shell utilities, which were also terrible).

Replacing the compiler on a traditional commercial Unix is a lot easier than replacing the C library, because the C library isn't just the functions defined in clause 7 of the C standard; as you have noticed, it also provides the lowest-level interface to the kernel, and often that wasn't very well documented. glibc did at one time at least sort-of support a bunch of these Unixes, but nowadays it can only be used with Linux and an experimental kernel called the Hurd. By contrast, GCC supports dozens of different CPUs and kernels, and Linux supports dozens of different CPUs.

If you write your own C library and/or kernel, it is relatively easy to write a "back end" so that GCC can generate code for them as a cross-compiler, and somewhat more difficult to port GCC to run in that environment. You may also need to write a back end for the assembler and linker, which are yet a fourth project ("GNU Binutils"). Porting glibc to a new CPU running Linux is a large but straightforward task; porting glibc to a new operating system is hard, especially if that OS is not Unix-ish. (Windows is decidedly not Unix-ish, so much so that when Microsoft wanted to make it easier to run programs written for Unix under Windows, the path of least resistance was to bolt an in-house clone of the Linux kernel onto the side of the NT kernel. I am not making this up.)

If you write your own C compiler, you will have to make it conform to the expectations of the library and kernel that it is generating code for. A lot of that is documented in the "ABI" specification for the environment you're working in, but not all, unfortunately.

If that doesn't clarify, please let us know what is still unclear.

zwol
  • 135,547
  • 38
  • 252
  • 361
  • 1
    It is generally *not* necessary to touch GCC at all when all you are doing is replacing GLIBC with newlibc (as M.M already noted in comments). – Employed Russian May 22 '18 at 14:25
  • @EmployedRussian If you make your newlibc a GLIBC lookalike, yes, sure. – zwol May 22 '18 at 16:00
  • No: you *don't* need to make newlibc look anything like GLIBC. GCC makes almost no assumptions about the libc it's going to compile and link against. – Employed Russian May 22 '18 at 17:58
  • @EmployedRussian That's ... really, profoundly not true. I don't know how you got that impression. – zwol May 22 '18 at 19:28
  • You are profoundly confused, but whatever. All it takes to link with a different newlibc is `-nostdinc`, `-nostartfiles` and `-nostdlib`. Supply appropriate newlibc pieces, and you are *done*. No changes to GCC proper are necessary. – Employed Russian May 22 '18 at 20:58
  • You go try that, starting from scratch (with a -linux-gnu configuration for gcc), and make a list of all the places where your "newlibc" must do something just the way glibc does it and that something isn't specified by C, POSIX, or the ABI. I assure you that you will find that that list is quite long. (Most of the things on my mental version of this list have to do with expected nonstandard contents of header files, fyi.) – zwol May 22 '18 at 21:01