gcc: NOLOAD and .noinit

"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:

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.

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?

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.

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.

Thank you for wasting your time for this description of loaders.

Correct.

You could always look at the manual:

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

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.

Correct.

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

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.

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