为什么glibc库使用汇编

Question

我正在看这个页面:https ://sys.readthedocs.io/en/latest/doc/01_introduction.html
,它解释了glibc如何进行系统调用.
在其中一个例子的代码进行检查,并且证明,这最后一条指令的glibc确实给真正做一个系统调用(意味着中断给CPU)是用汇编....那么,为什么在装配的glibc的一部分？通过在装配中写下那么小的部分有什么优势吗？
此外,运行时的共享库已经编译为机器代码正确吗？
那么为什么在编译之前使用两种不同的语言会有什么优势呢？谢谢.

Answer 1

答案非常简单 - 因为C不包括系统调用(因为它一般不包括任何物理硬件,并且更喜欢用抽象机器表达自己),所以没有C构造glibc可以用来执行系统调用.

有人可能认为编译器可以提供一种内在的功能,但是因为在Linux中,glibc实际上是编译器适合工具的一部分(也包含CRT),实际上没有必要,glibc可以完成这项工作.

此外,最后,但并非最不重要,在现代CPU中,系统调用通常不是中断.相反,它是一个特定的指令(syscall在x86_64中).

Answer 2

我想回答一下你的这个问题：

另外，运行时的共享库已经编译为机器代码，正确吗？那么为什么在编译之前使用两种不同的语言会有优势呢？

SergeyA 正确地指出，没有任何 C 构造（即使具有所有 GCC 扩展）会导致编译器发出指令syscall。这并不是 C 库应该做的唯一不能纯粹用 C 编写的事情：setjmpand的实现longjmp，makecontextandsetcontext的实现，调用 的“入口点”代码main，当您返回时返回的“蹦床”。从信号处理程序返回，以及其他几个低级位都需要一点点手写汇编。（练习：它们有什么共同点？）

但将汇编语言混合到主要用 C 编写的程序中还有另一个原因。 这是glibc 中 for x86-64的几种实现之一memcpy。它是 3100 行手写的汇编语言和预处理器宏。它的作用可以用四行 C 语言来表达。为什么有人会这么麻烦呢？ 速度。 编译器总是越来越接近，但在从关键的最内层循环中挤出每个最后可能的循环时，它们还没有完全击败人类大脑。（值得一提的是，在 2018 年初，glibc 开发人员花了很多时间math.h用 C 替换手写的函数汇编实现，因为编译器已经赶上了这些，而且 C 的可维护性要高得多。）

然而，第三个答案与 glibc 并不是特别相关，但在其他地方出现了很多，那就是你的程序中可能有两种不同的语言，因为它们中的每一种都更擅长解决你的问题。统计语言 R 大部分是用 C 实现的，但它的一堆数学原语是（或者曾经是，我有一段时间没有检查过）用 FORTRAN 编写的，因为 FORTRAN 仍然是数值计算奇才思考的语言。 FORTRAN 被编译为机器代码，原则上你可以用 C 重写所有 FORTRAN，但没有人愿意这样做。