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

Groups > comp.arch.embedded > #31021

Re: gcc: NOLOAD and .noinit

Show all headers | View raw

Il 19/03/2022 11:33, David Brown ha scritto:
> 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).  

So NOLOAD is just an "attribute" of a section, but doesn't change 
allocation and addresses computed by the linker, isn't it?

This attribute is used by JTAG programmer that will avoid programming 
sections marked as NOLOAD.
However this arises another question. What about .bss sections? They are 
in RAM, but they shouldn't be "loaded" by the programmer (they will be 
zeroed during startup code). How the JTAG/SWD probe know .bss sections 
shouldn't be loaded?


> For the commonly used sections, both
> ".bss" and ".noinit" sections will be marked "NOLOAD", 

Really? In my case .bss sections aren't marked as NOLOAD (from this my 
previous question).

     /* MAIN BSS SECTION */
     .bss : ALIGN(4)
     {
         _bss = .;
         PROVIDE(__start_bss_RAM = .) ;
         PROVIDE(__start_bss_SRAM_UPPER = .) ;
         *(.bss*)
         *(COMMON)
         . = ALIGN(4) ;
         _ebss = .;
         PROVIDE(__end_bss_RAM = .) ;
         PROVIDE(__end_bss_SRAM_UPPER = .) ;
         PROVIDE(end = .);
     } > SRAM_UPPER AT> SRAM_UPPER

I think there's a big difference between .bss and .data sections: .data 
sections are associated to real data (numbers that are init values for 
that part of memory). These numbers are present and written in the 
output executable object file.

On the contrary, .bss sections aren't associated to concrete numbers, 
because they are uninitialized (they will be simply zeroed by startup code).

If a .data section has an address, a size and some numbers, .bss has 
only an address and a size.

So this could be the reason why my build system doesn't use NOLOAD for 
.bss sections: a JTAG programmer will skip loading/programming of .bss 
sections, because there aren't any numbers to write for them.


> 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