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.
gcc: NOLOAD and .noinit
Started by ●March 19, 2022
Reply by ●March 19, 20222022-03-19
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.)
Reply by ●March 19, 20222022-03-19
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.
Reply by ●March 19, 20222022-03-19
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.)
Reply by ●March 19, 20222022-03-19
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.
Reply by ●March 19, 20222022-03-19
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.)
Reply by ●March 19, 20222022-03-19
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
Reply by ●March 21, 20222022-03-21
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
