LD and NOLOAD sections: Understanding strange LMA value - linker

Question

I'm writing a baremetal kernel, and I have trouble understanding the output of ld in the case of a NOLOAD section. I am declaring symbols that only exists with MMU activated, so the VMA and LMA are not the same.
I used to declaring such a section like this:
_foobar_start = .;
.foobar : AT(ADDR(.foobar) - VA_PA_OFFSET)
{
*.o(.foobar.section*)
}
_foobar_end = .;
Now one of my section's content is loaded by the boot loader, so I only want to declare the VMA symbols to be used at runtime, to access the data, so I tried the NOLOAD attribute:
_foobar_start = .;
.foobar (NOLOAD) :
{
. += SIZE_OF_FOOBAR;
}
_foobar_end = .;
I know I don't care about the LMA in this case, but I expected to see something like, where LMA = VMA (see LD manual):
.foobar 0x000000004002c000 0x353c load address 0x000000004002c000
but I get something with a strange LMA that I don't make sense of:
.foobar 0x000000004002c000 0x353c load address 0x0000000001900000
If I force the VMA = LMA in the script using
.foobar (NOLOAD) : AT(_foobar_start)
everything seems fine and I see only
.foobar 0x000000004002c000 0x353c
Even without forcing VMA = LMA, the resulting ELF is ok, but I get some warnings at compile time because of other sections (toto is another section):
warning: dot moved backwards before `.toto
and I'd like to get read of those.
Is there a reason I don't get LMA = VMA when specifying NOLOAD ?
EDIT: here is full linker file triggering the problem. I added some comments to pin points the issues
OUTPUT_ARCH(CONFIG_LINKER_ARCH)
OUTPUT_FORMAT(CONFIG_LINKER_FORMAT)
_kern_phys_base = OCRAM_BASE_PA + OCRAM_OFFSET;
_kern_offset = KERNEL_VA_PA_OFFSET;
SECTIONS
{
. = _kern_phys_base;
_start_image_addr = .;
. = ALIGN(0x1000);
_early_text_start = .;
.early_text :
{
KEEP(*(.text.boot))
KEEP(*(.text.mmu))
}
. = ALIGN(4);
.early_rodata :
{
*(.rodata.boot*)
*(.rodata.mmu*)
}
_early_text_end = .;
. = ALIGN(0x1000);
_early_data_start = .;
.early_data :
{
*(.data.boot)
}
_early_data_end = .;
. = ALIGN(0x4000);
_early_bss_start = .;
.early_bss :
{
*(.bss.mmu)
*(.bss.boot)
}
. = ALIGN(16);
_early_bss_end = .;
_early_end = .;
/*
* The following part is accessed only once the MMU has been
* activated, so we first need to jump into "high" memory
*/
. += _kern_offset;
. = ALIGN(0x1000);
_text_start = .;
.text : AT(ADDR(.text) - _kern_offset)
{
*(.text .text.*)
}
_text_end = .;
. = ALIGN(0x1000);
_rodata_start = .;
.rodata : AT(ADDR(.rodata) - _kern_offset)
{
*(.rodata*)
}
_rodata_end = .;
. = ALIGN(4);
_arm_extab_start = .;
.ARM.extab : AT(ADDR(.ARM.extab) - _kern_offset)
{
*(.ARM.extab)
}
_arm_extab_end = .;
. = ALIGN(4);
_arm_exidx_start = .;
.ARM.exidx : AT(ADDR(.ARM.exidx) - _kern_offset)
{
*(.ARM.exidx)
}
_arm_exidx_end = .;
. = ALIGN(4);
_kernel_debug_info_start = .;
_kernel_debug_info_end = .;
. = ALIGN(4);
_emergency_code_vstart = .;
_emergency_code_vend = .;
/*
* This is where I use the NOLOAD, with AT this time
* This 'archive' part is not located in OCRAM, but some
* where else in RAM
*/
_archive_point_save = .;
. = DDR_BASE_VA;
. = ALIGN(512);
_archive_start = .;
.archive_data (NOLOAD) : AT(_archive_start)
{
codes.o(.rawdata*)
}
_archive_end = .;
. = _archive_point_save;
/* Back to OCRAM VMA */
. = ALIGN(0x1000);
_data_start = .;
.data : AT(ADDR(.data) - _kern_offset)
{
*(.data*)
}
_data_end = .;
. = ALIGN(32);
_bss_start = .;
.bss : AT(ADDR(.bss) - _kern_offset)
{
*(.bss .bss.*)
}
. = ALIGN(16);
_bss_end = .;
/*
* Second location, also in RAM, just after the '.archive_data' section
* This time I didn't put the AT to show the difference in output
*/
_dyn_archive_point_save = .;
. = _archive_end;
. = ALIGN(0x1000);
_dyn_archive_start = .;
.dyn_archive (NOLOAD) :
{
. += _dyn_archive_space;
}
_dyn_archive_end = .;
. = _dyn_archive_point_save;
/* Back to OCRAM VMA */
. = ALIGN(0x1000);
_kernel_stack_guard = .;
. += 0x1000;
.stack (NOLOAD) :
{
_kernel_stack_end = .;
/* 2 pages of 4 kB */
. += 0x2000;
_kernel_stack_start = .;
}
_kernel_image_end = .;
}
And here is the output of objdump -x:
build/kernel/kernel.elf: file format elf32-littlearm
build/kernel/kernel.elf
architecture: arm, flags 0x00000102:
EXEC_P, D_PAGED
start address 0x00910000
Program Header:
0x70000001 off 0x0003072c vaddr 0x4003072c paddr 0x0093072c align 2**2
filesz 0x000000a0 memsz 0x000000a0 flags r--
LOAD off 0x00010000 vaddr 0x00910000 paddr 0x00910000 align 2**16
filesz 0x00002828 memsz 0x00008000 flags rwx
LOAD off 0x00018000 vaddr 0x40018000 paddr 0x00918000 align 2**16
filesz 0x000199e0 memsz 0x0001fa28 flags rwx
LOAD off 0x00038000 vaddr 0x41028000 paddr 0x01928000 align 2**16
filesz 0x00000000 memsz 0x00100000 flags rw-
LOAD off 0x00039000 vaddr 0x40039000 paddr 0x40039000 align 2**16
filesz 0x00000000 memsz 0x00002000 flags rw-
LOAD off 0x00040000 vaddr 0x41000000 paddr 0x41000000 align 2**16
filesz 0x00000000 memsz 0x00028000 flags rw-
private flags = 5000200: [Version5 EABI] [soft-float ABI]
Sections:
Idx Name Size VMA LMA File off Algn
0 .early_text 000015c0 00910000 00910000 00010000 2**5
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .early_rodata 00000030 009115c0 009115c0 000115c0 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .early_data 00000828 00912000 00912000 00012000 2**3
CONTENTS, ALLOC, LOAD, DATA
3 .early_bss 00004000 00914000 00914000 00012828 2**14
ALLOC
4 .text 000142d8 40018000 00918000 00018000 2**5
CONTENTS, ALLOC, LOAD, READONLY, CODE
5 .rodata 000036c0 4002d000 0092d000 0002d000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .ARM.extab 0000006c 400306c0 009306c0 000306c0 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 .ARM.exidx 000000a0 4003072c 0093072c 0003072c 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
8 .archive_data 00028000 41000000 41000000 00040000 2**0
ALLOC
9 .data 000009e0 40031000 00931000 00031000 2**3
CONTENTS, ALLOC, LOAD, DATA
10 .bss 00006048 400319e0 009319e0 000319e0 2**3
ALLOC
11 .dyn_archive 00100000 41028000 01928000 00038000 2**0
ALLOC
12 .stack 00002000 40039000 40039000 00039000 2**0
ALLOC
13 .comment 0000002d 00000000 00000000 000319e0 2**0
CONTENTS, READONLY
14 .ARM.attributes 00000037 00000000 00000000 00031a0d 2**0
CONTENTS, READONLY
SYMBOL TABLE:
no symbols
As you can see: .archive_data and .stack correctly get VMA = LMA but .dyn_archive doesn't. If I remove the AT of .archive_data, I get the same behavior than .dyn_archive with the address 0x1900000

Answer 1

It seems my last comment is valid, as confirmed (at least to the extend of our interpretation of the manual) on the binutils ML
The warning where triggered by the "LMA goes backwards" scenario, and correctly updating LMA each time . is updated by hand is the correct way to go.