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

Groups > comp.arch.embedded > #31022

Re: gcc: NOLOAD and .noinit

Show all headers | View raw

Il 19/03/2022 12:46, Hans-Bernhard Bröker ha scritto:
> 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.

You're right, .bss has only ALLOC attribute, while .text and .data have 
LOAD attribute too.

It's strange because, as I wrote to David, my linker script doesn't use 
NOLOAD for .bss sections.


> 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.

Thank you for wasting your time for this description of loaders.

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