c编译器与c标准库的关系

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

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

最佳答案
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移植到新的操作系统很难,特别是如果该操作系统不是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”规范中,但遗憾的是并非全部.

如果没有澄清,请告诉我们尚不清楚的地方.

转载注明原文:c编译器与c标准库的关系 - 代码日志