c编译器与c标准库

Question

我最近一直在做很多关于glibc函数如何在linux中包装系统调用的内容。我想知道glibc和GNU C编译器之间的关系。
让我们说例如我想编写自己的C Standard实现并编写一个名为“newglibc”的新库，我稍微改变一下。例如，我在系统调用之前和之后采取更多检查和操作。我是否必须编写新的编译器？或者我可以使用相同的GNU gcc编译器吗？

如果编译器与库完全分离，那么有人能够在Windows系统上使用gcc，如果他们可以将它变成.exe并提供windows提供的标准C库吗？ 谢谢

Answer 1

Linux内核，GNU C库（“glibc”）和GNU编译器集合（gcc）是三个独立的开发项目。它们通常经常一起使用，但它们并非必须如此。名字中带有“GNU”的人是GNU项目的正式部分; Linux不是。

C标准没有区分“编译器”和“库”;这是委员会的所有“实施”。 GCC是一个独立的glibc开发项目，这在很大程度上是一个历史性的事故：但是在当天，每个商业Unix版本都附带了自己的C库和编译器，而且它们非常糟糕 ，按体积计90％的错误是典型的。 GNU开始为编译器提供一个不太可怕的替代品（以及shell实用程序，这也很糟糕）。

在传统的商业Unix上替换编译器比替换C库容易得多，因为C库不仅仅是C标准第7节中定义的函数。正如您所注意到的，它还提供了内核的最低级别接口，并且通常没有很好地记录。 glibc曾经一次至少支持一堆这些Unix，但现在它只能用于Linux和一个名为Hurd的实验内核。相比之下，GCC支持许多不同的CPU和内核，Linux支持许多不同的CPU。

如果您编写自己的C库和/或内核，编写“后端”相对容易，以便GCC可以为它们生成代码作为交叉编译器，并且将GCC移植到在该环境中运行。您可能还需要为汇编程序和链接程序编写后端，这是第四个项目（“GNU Binutils”）。将glibc移植到运行Linux的新CPU是一项很大但很简单的任务;将glibc移植到新操作系统是 hard ，特别是如果该操作系统不是Unix-ish。 （Windows 决定不是Unix-ish，以至于当微软希望在Windows下运行为Unix编写的程序更容易时，阻力最小的路径是bolt an in-house clone of the Linux kernel onto the side of the NT kernel。我没有这样做。）

如果您编写自己的C编译器，则必须使其符合为其生成代码的库和内核的期望。很多内容记录在您正在使用的环境的“ABI”规范中，但不幸的是，并非所有。

如果不澄清，请告诉我们尚不清楚的事情。