c - 哪种机制知道程序的入口点是main()

Question

应用程序如何知道其入口点是main()函数？

我知道一个应用程序不知道它的入口点是main()-它通过语言规范直接指向main()函数。

那时，规范实际在哪里声明？例如，在C语言中，入口点应为main()函数。谁为程序提供这种机制？操作系统还是编译器？

在Visual Studio中分解了一个规范的简单“ Hello World”示例后，我想到了这个问题。

在此代码中，只有几行和一个函数main()。

但是反汇编后，内存空间中有很多定义和宏，main()并不是唯一的声明和定义。

下面是分解部分的屏幕截图。我也知道语言定义中有一个严格的规则，只有一个main()函数必须定义并存在。

总结一下我的问题：我想知道哪种机制指导或设置main()函数作为应用程序的入口点。

Answer 1

应用程序不知道main（）是入口点。首先，尽管您的情况是我们假设C不是C ++。

对于C，“ C”入口点是main（）。但是您不能仅仅从那里开始执行代码，因为我们在C语言中有很多假设（例如，规则）需要初始化，而.bss必须清零。

unsigned x = 1;
unsigned int y;

我们期望当main（）被命中时x = 1。并且大多数人都假设并且可能是当时指定y = 0，但我还是不会做这个假设。

我们还需要一个堆栈指针，并需要处理argc / argv。如果使用C ++，则必须完成其他工作。即使对于C依赖。

该应用程序通常不知道这些。您可能正在使用C库，并且该库应负责/应该先于main（）的引导程序代码以及该链接程序的链接程序脚本，因为引导程序和链接程序脚本密切相关。有人可能会基于某些实现而争论，如我们所知，使用gnu，C库可与工具链分离，您可以从不同的库中进行选择，并且库具有不同的引导程序和链接程序脚本。但是我敢肯定，有许多紧密相关的关系，而且库与操作系统之间也存在关系，因为许多C库调用最终以一个或无数个系统调用结尾。

您设计一个操作系统，假设该操作系统支持运行时可加载应用程序，这是操作系统设计的一部分，它是操作系统加载程序支持的文件格式，操作系统加载程序要支持的功能以及它们与文件格式的重叠方式，而不是对于OS来说，定义文件格式并不常见，但是对于elf和其他人（无疑是偶然/独立创建的），您就有机会让新OS使用像elf这样的现有容器。操作系统设计及其加载器决定了很多事情，而与所有这些匹配的C库必须遵循所有这些规则，如果将其集成到编译器中，则编译器也必须发挥作用。

不是应用程序知道它是系统设计的一部分，而该应用程序只是所有这些的奴隶，当您在该平台上针对该平台进行编译时，所有这些规则和关系都在起作用，您将难题的很小一部分，其余部分已经就位，支持什么文件格式，每种格式需要什么信息，编译器/库解决方案必须提供什么规则。系统设计指示加载程序或应用程序是否将.data和.bss归零，而我的意思是引导程序而不是程序的用户部分，因此无法在C中引导C，因为C需要引导程序如果该引导程序在C中，则C需要一个引导程序，依此类推。

int main ( void )
{
    return 0;  
}

编译该程序时，后台发生了很多事情，而不仅仅是实现该代码可能需要的几条指令。

在Windows，Linux和Mac上编译该程序，并针对每个库或C库使用不同的编译器来编译每个程序的不同版本，以及针对每个库使用不同版本等。您应该期望看到的是即使相同的目标ISA，同一台计算机甚至，某些组合可能会为该功能选择相同的几条指令，因此它所包含的内容可能相似但不相同。如果某些实现彼此之间非常不同，将不会感到惊讶。

而这完全是用于将程序加载到ram中并运行它们的成熟操作系统，因为如果差异更大，嵌入式事情也不会感到惊讶。在一个完整的操作系统中，您可能希望看到一个mmu，并且应用程序至少会获得一个基于零的.text，.data，.bss地址空间，因此所有解决方案在二进制中的顺序相同，但是每个的大小可能特定于实现。顺序/大小可能因C库版本或编译器版本等而异。

魔术在系统设计中。那不是魔术，而是设计。 main（）无法直接输入，并且语言的各个部分仍然可以正常工作，例如.data和.bss init，可以在输入之前解决堆栈指针，但是.data和.bss的方式和位置是特定于应用程序的，因此无法处理通过从OS到main的简单分支。

可以通过多种方式告诉您工具链的链接器，该工具/目标，命令行选项或链接器脚本选项或放置在标签上的某些特殊符号或其他设计师选择。 main被假定为C入口点，尽管这实际上并不意味着它之前可能有一些C代码，但通常存在一定数量的asm（带有C的Cant bootstrap C），然后再执行一个或多个步骤来维护main （）。