Am 19.03.2022 um 08:02 schrieb pozz:
> In embedded systems we don't have program loader, at least in my case
> there isn't any program loader.
There is a loader; it's just not running on the target. A linker for an
embedded target is actually three tools in one, which traditionally
where thought of as separate: the actual linker, the locator, and (part
of) the loader.
The linker proper just has the job of connecting symbols referenced by
some modules, to matching symbol definitions in other modules.
The next phase, the locator, positions the resulting sections where they
have to go in available memory, and resolves symbolic addresses to
actual places in target memory space.
The job of the loader is split between the tool we usually just call a
linker, the raw/hex file extraction tool, flash programmers, and the
debugger. They share the job of moving the contents of the code and
data sections from the locator's output into actual target memory.
To that end the locator has to mark which sections the loader should
load, and which it doesn't have to handle. That's kept as a "LOAD"
attribute you can find, e.g. in the section headers of the generated ELF
file. You can inspect these attributes by 'objdump -h'. BSS-style
sections never get the LOAD attribute, because they're not part of the
program image that the flasher or debugger has to transfer to the
hardware --- they only exist at run-time.
Desktop linkers, OTOH, will usually perform just parts of those three
phases, depending on the type of executable and operating environment.
E.g. linking an MS-DOS "COM" program does almost all of it, leaving out
only the actual transfer from disk to memory. That's almost exactly
what an embedded linker usually does.
If instead you build an MS-DOS EXE file, it stops early in the locator
phase, leaving the task of placing the sections in memory, and the bulk
of replacing virtual addresses by actual ones to DOS. The file on disk
is a collection of memory sections to be loaded, and recipes for
patching up references from one to the other (called "relocations"). A
linker producing a typical program for, e.g. Windows or Linux does not
even fully complete the linker stage, because it cannot finally resolve
links to dynamically linked, shared libraries.