What is the use of Crt.s file?

Question

I know that they are used to call main(), but if that is the only purpose then what is the point of having different crt files. Why not use the default one instead of creating your own ?

Answer 1

The CRT files are the C runtime files. The one you're most likely to have encountered is crt0.S, which is the name most systems give the first code that executes as part of a given process. This is essentially the shim layer that converts between the system ABI (ie, what the Linux loader provides) and the language ABI (ie, the code that users can change). As such, the implementation is coupled to both the language runtime (ie, the C library) and the system runtime (ie, the kernel). The result here is that there tends to be a single crt0.S per kernel/libc pair.

If that was the only case in which crt0.S needed to be written then everything would be fine and you'd probably never have heard of it -- just like you probably haven't heard of any of the other esoteric bits of the toolchain. The part where all this starts to become an issue is when you consider embedded systems -- specifically, software stack on embedded systems tends to be somewhat adhoc. The result is that there is rarely a standard interface between the system runtime (which is probably just whatever the processor does on reset) and the language runtime (which is some restricted subset of C). Since crt0.S is the shim between these, there tends to be a different one for system.

As far as a concrete example: In most POSIX ABIs, a loader is responsible for setting up all the segments in the ELF before transferring control to it. In embedded systems this is not the case, so the CRT must be written in a way such that it can initialize itself with only a subset of the segments having been set up. Thus, a POSIX crt0.S wouldn't have to initialize the data segment or the stack pointer while an embedded crt0.S usually does.

In the other direction, POSIX C runtimes tend to support many complicated features like thread-local storage, dynamic linking, error handling, and signals. Embedded runtimes tend to only support a restricted subset of these features (usually for space reasons), which makes a POSIX crt0.S unusable.