CODEWITHSUNDEEP
linkerd
Dmitry Bubnenkov
Dmitry Bubnenkov

Reputation: 9859

Is it possible to produce working binary without linker?

As far as I know compiler convert source code to machine code. But this code do not have any OS-related sections and linker add them to file.

But is it's possible to make some executable without linker?

Upvotes: 5

Views: 978

Answers (2)

Rab
Rab

Reputation: 510

Answering your question very literally - yes, it is possible to make an executive file without a linker: you don't need a compiler or linker to generate machine code. Binaries are a series of opcodes and relevant information (offsets, addresses etc). If you open a binary editor then type out some opcodes and make a program. Save and run it.

Of course the binary will be processor specific, just as if you had compiled a binary (native) executive. Here's a reference to the Intel x86 opcodes. http://ref.x86asm.net/coder32.html.

If you're however asking, "Can I compile a source file directly into an executive file without a linker?" then speaking purely: no - unless the compiler has aspects of a linker integrated within it. The compiler generates intermediate objects that are passed on to the linker to "link" them into a binary such as a library or executive. Without the link step the pipeline is not complete.

Upvotes: 3

Richard Andrew Cattermole
Richard Andrew Cattermole

Reputation: 484

Let's first make a statement that is to be considered true, compilers do not generate machine code that can be immediately executed (JIT's do, but lets ignore that).

Instead they generate files (object, static, dynamic, executable) which describe what they contains as well as groups of symbols. Symbols can be global variables or functions.

But symbols just like the file itself contain metadata. This metadata is very important. See the machine code stored in a symbol is the raw instructions for the target architecture but it does not know where memory is stored.

While modern CPU's give each process its own address space, a symbol may not land and probably won't land in the same address twice. In very recent times this is a security measure, but in past its so that dynamic linking works correctly.

So when the OS loads up an executable or shared library it can place it wherever it wants and by doing so make it not repeatable. Otherwise we'd all have to start caring and saying "this file contains 100% of the code I intend to execute". Usually on load the raw binary in the symbol table get transformed by patching it with the symbol locations in RAM. Making everything just work.

In summary the compiler emits files that allow for dynamic patching of assembly prior to execution. If it didn't, we would be living in a very restrictive and problematic world.

Linkers even have scripts to change how they operate. They are a very complex and delicate piece of software required to make our programs work.

Have a read of the PE-COFF and ELF standards if you want to get an idea of just how complex those formats really are.

Upvotes: 2

Related Questions