GCC编译C程序依赖项疑问：vdso、ld等相关技术问题咨询

1. 为什么linux-vdso.so.1没有被包含在libc中？ #

• linux-vdso.so.1是内核直接映射到用户进程地址空间的虚拟动态共享对象（VDSO），属于内核组件而非用户态的libc范畴。
• 它的实现与内核版本强绑定，内核会根据自身特性提供高频系统调用（如gettimeofday）的最优路径，若将其纳入libc，无法随内核版本动态更新优化。
• libc仅通过约定的符号调用VDSO中的实现，二者是协作关系，而非包含关系。

2. 为什么ld会被动态链接到可执行文件？它在运行时会被使用吗？ #

• 这里的ld指的是动态链接器ld-linux-x86-64.so.2，而非编译时的链接工具ld。它会被标记为可执行文件的interpreter（解释器），内核启动程序时会优先运行它。
• 运行时它负责：加载程序依赖的所有动态库（如libc.so.6）、重定位符号地址、初始化全局变量，完成这些工作后才会跳转到程序的main函数执行。
• 只有静态编译（gcc -static main.c -o main）的程序才不需要它，此时所有依赖都被打包进可执行文件。

3. 程序依赖的libgcc和crt0是静态链接的吗？ #

• crt0（C运行时启动代码）：负责初始化进程环境（设置栈、调用全局构造函数等），最终调用main。默认动态编译模式下，crt0相关的目标文件（如crtbegin.o、crtend.o）是静态链接到可执行文件中的，不会作为动态依赖存在。
• libgcc：包含GCC生成代码所需的辅助函数（如浮点运算、栈展开、异常处理）。默认是动态链接的，可通过ldd main查看是否存在libgcc_s.so.1；若编译时添加-static-libgcc参数，则会将其静态链接进程序。

4. 必然存在隐藏的-I参数使程序能找到libc头文件，这个判断正确吗？这些头文件在哪里？ #

• 判断正确。GCC编译时会自动添加默认的-I参数，无需手动指定即可查找系统头文件。
• 在Ubuntu-WSL x64环境下，libc头文件的常见位置：
  • /usr/include：标准C头文件（如stdio.h、stdlib.h）的主目录
  • /usr/include/x86_64-linux-gnu：x86_64架构专属的系统头文件
• 可通过gcc -v main.c -o main命令查看GCC实际使用的所有头文件搜索路径，输出中#include <...> search starts here:部分会列出完整路径。

5. 是否还遗漏了其他依赖项？ #

• 对于默认动态编译的简单C程序，你已覆盖核心依赖：动态链接器、libc、VDSO。
• 可能的额外依赖：
  • libgcc_s.so.1：若使用了动态版的libgcc
  • libpthread.so.0：若程序调用了线程相关函数（如pthread_create）
  • 静态编译的程序会将所有依赖（libc、libgcc、crt代码等）打包进可执行文件，运行时无额外动态依赖（VDSO由内核自动映射，不属于用户态依赖）

内容的提问来源于stack exchange，提问作者gberth