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


Groups > comp.arch.embedded > #31018

Re: gcc: NOLOAD and .noinit

From David Brown <david.brown@hesbynett.no>
Newsgroups comp.arch.embedded
Subject Re: gcc: NOLOAD and .noinit
Date 2022-03-19 11:33 +0100
Organization A noiseless patient Spider
Message-ID <t14bi6$c07$1@dont-email.me> (permalink)
References <t13v61$b72$1@dont-email.me>

Show all headers | View raw


On 19/03/2022 08:02, pozz wrote:
> I usually don't touch linker script of my development system, sincerely
> I can't read every details of a linker script, so I'm in trouble now.
> 
> As explained in my previous post, I need to avoid zeroing a static big
> variable, because it is allocated in SDRAM and SDRAM isn't available
> when zeroing of bss sections (and initialization of data sections) occurs.
> 
> My development system allows me to use .noinit section, so I'm studying
> how it works.
> 
> MCUXpresso IDE generates complete linker scripts that automatically
> manages .noinit sections. These sections aren't added to section table
> that startup code reads to reset sections of RAM.
> 
> What I don't understand is the presence of NOLOAD directive in the
> linker script:
> 
>     [...]
>     The linker will process the section normally, but will
>     mark it so that a program loader will not load it into
>     memory.
> 
> In embedded systems we don't have program loader, at least in my case
> there isn't any program loader. Code and constant variables are already
> at the right addresses at startup (Flash is already written). Only
> variables that changes at runtime must be initialized in RAM, but this
> is done by startup code, not by a program loader.
> 
> So, if startup code doesn't reset .noinit sections (because they aren't
> added in bss section table by the linker script), what's the exact
> purpose of NOLOAD directive?
> 
> I was tempted to remove NOLOAD directive from the linker script
> generated by MCUXpresso, but it re-generates it at every build.
> 

"NOLOAD" basically means the section is not part of the binary image
that gets loaded to the device - such as by jtag download or other
programs that use the "elf" file.  When you use objcopy to generate
".hex" or ".bin" files, NOLOAD sections are omitted (unless you go out
of your way to include them).  For the commonly used sections, both
".bss" and ".noinit" sections will be marked "NOLOAD", whereas ".text",
".readonly" and ".data" sections will be "LOAD".  (Variables in the
".data" sections have two sets of addresses - their "load" addresses for
the address in flash or other images of the initial value, and their
"link" addresses for their run-time variable address.)

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