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

Groups > comp.arch.embedded > #31017 > unrolled thread

gcc: NOLOAD and .noinit

Back to article view | Back to comp.arch.embedded

Contents

  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

#31017 — gcc: NOLOAD and .noinit

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.

[toc] | [next] | [standalone]

#31018

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

[toc] | [prev] | [next] | [standalone]

#31021

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

[toc] | [prev] | [next] | [standalone]

#31023

On 19/03/2022 16:20, pozz wrote:
> 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?
> 

Correct.

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

You could always look at the manual:

<https://sourceware.org/binutils/docs/ld/Output-Section-Type.html>

".bss" sections will already be marked "NOLOAD" by the compiler.  But
your new ".noinit" sections are not standard compiler-generated
sections, and probably default to normal loaded sections.


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

They will be marked NOLOAD in their input sections in the object file,
so the output section does not need to be marked explicitly in the
linker file.  It would do no harm to mark it as such.

You can see the attributes of the input sections by using "objdump -h"
on the object file.  There you'll see ".text" sections marked as
"CONTENTS, ALLOC, LOAD, READONLY, CODE", ".data" sections as "CONTENTS,
ALLOC, LOAD, DATA", and ".bss" sections as "ALLOC".  A manually
specified ".noinit" section will likely be marked like ".data" sections,
so you want to add the "NOLOAD" flag explicitly in the linker file.

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

Correct.

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

It skips them because the section is NOLOAD from the input section
flags, giving the same effect as NOLOAD in the linker file.

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

[toc] | [prev] | [next] | [standalone]

#31019

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.

[toc] | [prev] | [next] | [standalone]

#31022

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.

[toc] | [prev] | [next] | [standalone]

#31024

On 19.3.22 17.27, pozz wrote:
> 
> 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.


Please look at the unlinked .o file of some module accessing the
.bss section. The LOAD attribute is missing there, also.

An example:

tauno@ubuntu:~/sandbox/lm3/app$ arm-none-eabi-objdump -h stest.o

stest.o:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
   0 .text         00000000  00000000  00000000  00000034  2**1
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
   1 .data         00000000  00000000  00000000  00000034  2**0
                   CONTENTS, ALLOC, LOAD, DATA
   2 .bss          00001428  00000000  00000000  00000038  2**3
                   ALLOC
   3 .text.boot_thr 00000098  00000000  00000000  00000038  2**2
                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
   4 .text.net_thread 00000004  00000000  00000000  000000d0  2**1
                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
   5 .text.startup.main 0000008c  00000000  00000000  000000d4  2**2
                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
   6 .rodata       00000020  00000000  00000000  00000160  2**2
                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
   7 .comment      0000005a  00000000  00000000  00000180  2**0
                   CONTENTS, READONLY
   8 .ARM.attributes 0000002d  00000000  00000000  000001da  2**0
                   CONTENTS, READONLY

It is the assembly phase of the compilation (GNU as) which knows
about the .bss section and leaves the LOAD bit off.

-- 

-TV

[toc] | [prev] | [next] | [standalone]

#31025

In article <t13v61$b72$1@dont-email.me>, pozz  <pozzugno@gmail.com> 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.

I suspect you can come up with a linker-based solution, but I think you may
want to look at your problem differently.

In C/C++, you can form a pointer to any location you want.  So if your SDRAM
is at 0x2000_0000, just do:

char *sdram_ptr = (char *)0x20000000;

(For 64-bit systems, this will need to be 0x20000000L or something similar).

And then just use sdram_ptr[offset] to access whatever SDRAM location you
want--after SDRAM has been initialized.

Kent

[toc] | [prev] | [standalone]

Back to top | Article view | comp.arch.embedded

csiph-web