Doubts about the compilation and linking phase of a C Program

The internal format of the object files varies from compiler to compiler, they are not required to follow a pattern about it, but basically what they have there is the list of functions and global variables of your .c file, already in instructions. The labels for jumps and function calls are still temporary, the linker will fix them when the final executable is created.

And about includes, always think of them as giving you a ctrl + c ctrl + v of the file you're including in the source file. The compiler needs this to know the name of the functions, their parameters, and the layout of the data structures. So when calling a function that receives two ints the compiler knows that it has to generate instructions to put those parameters on the stack before making the call. So yes, it's like a link itself, an empty space that the linker then replaces with the "real" address of that function in the executable.

The #include is something that only serves the compiler. You already have ask about it .

I've broadly answered how a compiler works .

The object has essentially the binary code that it should execute. This code is bytes that make sense to instruct the processor.

Of course, it has some information that helps linker mount the executable, public symbol table, relocation information, static data generated, reference definitions, debug information (when appropriate) , etc.

You can use objdump to see what's inside it. Or dumpbin if you use Microsoft.

Each one can have a format COFF is one of the formats .

To understand a bit about binary code operation already has a question .

The object is generated as a single build unit. The compiler assembles as it is informed, there is no correlation of a .c file and an object.

• Wikipedia article .
• Article with details .
• OSDev Article .