Printable View
Hello everyone! I have been using C/C++ with an IDE for a year now, but I wish to learn the ins and outs of the entire compiling and linking process for a compiler... maybe gcc. Does anyone have a link to a good, detailed tutorial/article on this?
I don't mean the commands gcc -c , gcc -o... I mean what goes on under the hood. Like which data variables are put in which segments, how the linking is actually done.
thanks
Umm ... all I get is the commands, which I already know from college or from the man pages. I am looking for things like what exactly happens when I enter gcc -o program myprogram.c. I know object file is created, but I want to know what exactly is contained in the object file. How the external symbols are resolved and things like that. Haven't found those online. I'll keep searching anyhow.Quote:
Originally Posted by Tux0r
Ok then you could try say xxd object.o for starters ;)Quote:
Originally Posted by tapti
Every source file is first compiled into assembly language (gcc -S), then assembled into an object file (gcc -c). Finally, object files are linked with the standard (and non-standard) libraries to make your binary.
GCC "outsources" the assembling phase to GNU Assember (as), and the linking phase to GNU Linker (ld). You can call all these things yourself, but GCC calls them for you.
Basically, compiler interprets code and turns it into assembly. However, with function calls that are to files that do not exist in the source file it compiles, it ignores them.
Later, the linker comes into play. The linker puts together all the files into a common binary.
The linker also searches for function calls you have in your code that the compiler could not generate code for. It searches .lib files to find that out where those functions are located. Typical examples are the C/C++ Standard Library which are usually put into some other source files or binaries. When the linker finds them, it generates the correct code for those function calls.
Then the final output, the binary is produced.
This is a rough overview on how the process is done.
Okay, but this seems to imply that all executables are statically linked, eg, once created they do not require those "other binaries" to exist, when in fact they do require them, hence they are (dynamically) linked.Quote:
Originally Posted by Elysia
Not only that, but saying, "It searches .lib files to find that out where those functions are located" is pretty misleading. That only happens on Windows, and the code may actually be stored in a corresponding .dll file -- not the .lib file. In fact, I think that .lib files are only used with Visual Studio (I could be wrong about this last part though).Quote:
Originally Posted by MK27
.lib files or .xxyyyzzzz files, doesn't matter. It searches SOME TYPE of files for this type of information. The extension type is irrelevant, because the principle is the same.
And I never said that the code (functions) are contained inside the .lib files. That may or may not be. Static libraries are indeed stored in the .lib files. I believe some stub code for functions is actually stored in the .lib file for dlls, too, but the actual function code is stored inside the .dll file.
Maybe I could add that the linker searches all the object files produced by the compiler and additional files, .lib files or whatever they're called for functions.
Then say static library instead of .lib file. This way he doesn't get confused when doing research on gcc (which is the compiler he said he is using).Quote:
.lib files or .xxyyyzzzz files, doesn't matter. It searches SOME TYPE of files for this type of information. The extension type is irrelevant, because the principle is the same.
Thanks for all the replies. I did some reading from the net also, on static and dynamic libraries (they are .dll on windows and .so on linux, am I right?) I've understood the following, please correct me if I'm wrong.
When I link a static library to my code, the object code of that static file is added or copied to my object file. It doesn't matter if the static library is later deleted from my disk. But when I link a shared library, then only a list containing the functions, provided by the shared library, is added to my object file. If I were to delete the shared library, I'd get an error while trying to run the object file.
Please tell me where I'm going wrong, if I am :)
Also, if I don't add the -S switch to gcc, it still does generate the assembly code as an intermediate step, doesn't it? It just doesn't write out the file.
Correct.Quote:
When I link a static library to my code, the object code of that static file is added or copied to my object file. It doesn't matter if the static library is later deleted from my disk. But when I link a shared library, then only a list containing the functions, provided by the shared library, is added to my object file. If I were to delete the shared library, I'd get an error while trying to run the object file.
Yeap, -S tells GCC to stop before the assembling phase, and -c tells it to stop after assembling (no linking).Quote:
Also, if I don't add the -S switch to gcc, it still does generate the assembly code as an intermediate step, doesn't it? It just doesn't write out the file.
Thank you everyone for your replies. It really helped me a lot.