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.

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

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.

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

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.

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

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

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