Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #31019

Re: gcc: NOLOAD and .noinit

Show all headers | View raw

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.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

gcc: NOLOAD and .noinit pozz <pozzugno@gmail.com> - 2022-03-19 08:02 +0100
  Re: gcc: NOLOAD and .noinit David Brown <david.brown@hesbynett.no> - 2022-03-19 11:33 +0100
    Re: gcc: NOLOAD and .noinit pozz <pozzugno@gmail.com> - 2022-03-19 16:20 +0100
      Re: gcc: NOLOAD and .noinit David Brown <david.brown@hesbynett.no> - 2022-03-19 16:49 +0100
  Re: gcc: NOLOAD and .noinit Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2022-03-19 12:46 +0100
    Re: gcc: NOLOAD and .noinit pozz <pozzugno@gmail.com> - 2022-03-19 16:27 +0100
      Re: gcc: NOLOAD and .noinit Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2022-03-19 18:57 +0200
  Re: gcc: NOLOAD and .noinit kegs@provalid.com (Kent Dickey) - 2022-03-21 04:43 +0000

csiph-web