flat assembler
Message board for the users of flat assembler.

Index > Main > What is a dynamic linker and CRT overhead exactly?

Author
Thread Post new topic Reply to topic
antos



Joined: 13 Jul 2016
Posts: 23
Location: Syria
antos 14 Jul 2016, 09:55
I disassembled C code with GDB and i see lots of code in outside of the concept of the program. After that i make a research about it. I learned most of code is coming from dynamic linker and CRT overhead. Why C/C++ do not use system calls? And what is a dynamic linker and how works it?

_________________
V0.01
Post 14 Jul 2016, 09:55
View user's profile Send private message Reply with quote
comrade



Joined: 16 Jun 2003
Posts: 1150
Location: Russian Federation
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:


  1. performance: code sharing and lower memory footprint - the OS can share the same copy of the CRT+STL for many programs. That is, if you have 10 programs running, all linking with the same CRT+STL, the OS only maintains a single copy of the CRT+STL in memory.
  2. servicing: an update to the master CRT+STL copy will update all programs using it.


There are also negative effects to dynamic linking: missing or mismatched libraries ("DLL hell" in Windows 95/9Cool.

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!
Post 30 Jul 2016, 05:00
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
antos



Joined: 13 Jul 2016
Posts: 23
Location: Syria
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.

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:


  1. performance: code sharing and lower memory footprint - the OS can share the same copy of the CRT+STL for many programs. That is, if you have 10 programs running, all linking with the same CRT+STL, the OS only maintains a single copy of the CRT+STL in memory.
  2. servicing: an update to the master CRT+STL copy will update all programs using it.


There are also negative effects to dynamic linking: missing or mismatched libraries ("DLL hell" in Windows 95/9Cool.

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!


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
Post 08 Aug 2016, 10:35
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20344
Location: In your JS exploiting you and your system
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?
Perhaps you are conflating a linker with the loader?

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.
Post 08 Aug 2016, 10:49
View user's profile Send private message Visit poster's website Reply with quote
antos



Joined: 13 Jul 2016
Posts: 23
Location: Syria
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.
Post 08 Aug 2016, 12:05
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20344
Location: In your JS exploiting you and your system
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.
The difference is just technical. Meaning, it is just the process used. In the case that we want to combine multiple objects into a single file then they are linked with a linker. But you can also link a single object file (linked with nothing else) and create an executable.

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.
Post 08 Aug 2016, 12:27
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.