flat assembler
Message board for the users of flat assembler.
Index
> Main > What is a dynamic linker and CRT overhead exactly? |
Author |
|
comrade 30 Jul 2016, 05:00
C/C++ do use system calls. They also provide and implement an abstraction layer around the OS, more commonly referred to as the CRT (C Runtime) and STL (for C++, Standard Template Library). This abstraction layer is what eases portability, and allows the same source code to compile against and run on different platforms (Windows, MacOS, Linux, etc). The cost (overhead) of this portability is extra code "outside of the concept your program" - this is the "crud" you see when you disassemble a program with GDB or IDA.
In addition to implementing a portability layer, the CRT is also responsible for implementing language features such as static object initialization/deinitialization: think of static C++ objects - who runs their constructors/destructors and when?. A linker is the tool (final stage of the build process) that combines your program (written by you) with the CRT/STL libraries (written by the compiler authors - Microsoft, GNU/GCC team, etc) into an executable file that one can run. There are two (complementary, orthogonal) forms of linking: static and dynamic. Static linking combines the multiple object files together at the time of compilation. If all object files and dependencies in a program are statically linked, then the program is monolithic and has no dependencies. Dynamic linking decouples and defers linking of certain objects until runtime. This decoupling has two positive effects:
There are also negative effects to dynamic linking: missing or mismatched libraries ("DLL hell" in Windows 95/9. Example of dynamically linked objects are .dll files on Windows, and .so files on Linux/BSD systems. There are different reasons where one may choose static linking, dynamic linking, or some combination of both. Hope that helps. Stay safe! |
|||
30 Jul 2016, 05:00 |
|
antos 08 Aug 2016, 10:35
comrade wrote: C/C++ do use system calls. They also provide and implement an abstraction layer around the OS, more commonly referred to as the CRT (C Runtime) and STL (for C++, Standard Template Library). This abstraction layer is what eases portability, and allows the same source code to compile against and run on different platforms (Windows, MacOS, Linux, etc). The cost (overhead) of this portability is extra code "outside of the concept your program" - this is the "crud" you see when you disassemble a program with GDB or IDA. I'm asking for clarification. How linkers are working? Is the OS allocating memory on the RAM and loads the CRT to this entry? And when i want to call a CRT function like printf, is my program jumps to this entry? _________________ V0.01 |
|||
08 Aug 2016, 10:35 |
|
revolution 08 Aug 2016, 10:49
antos wrote: How linkers are working? Is the OS allocating memory on the RAM and loads the CRT to this entry? And when i want to call a CRT function like printf, is my program jumps to this entry? A linker will produce the executable file (.exe, .dll, .so) from the source objects files. This only needs to be done once for each new version of the file. The loader will place the executable file into RAM and begin to "link" it (i.e. resolve addresses between modules) with the required resources in order to run it on the system. This is done each time the program runs. |
|||
08 Aug 2016, 10:49 |
|
antos 08 Aug 2016, 12:05
What is the difference between linked (ELF) and not linked (object file) files? When we compile an application with '-c' tag in GCC, we get an object file as output. When we link a GNU Linker, we get an executable file. What is the difference? I have questions about loaders too but it's out of the concept of this topic.
|
|||
08 Aug 2016, 12:05 |
|
revolution 08 Aug 2016, 12:27
antos wrote: What is the difference between linked (ELF) and not linked (object file) files? When we compile an application with '-c' tag in GCC, we get an object file as output. When we link a GNU Linker, we get an executable file. What is the difference? I have questions about loaders too but it's out of the concept of this topic. fasm can output an executable directly if you tell it to, so using object files as an intermediate step is not required, it is just a convenience to support modular development. |
|||
08 Aug 2016, 12:27 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.