[arch] linker ASSERT prevents invalid memory access

[vivek-jaluka]

Problem Statement

1. Incorrect calculation of _end_of_ram

• _end_of_ram indicates the last address that can be accessed. When we have KERNEL_LOAD_OFFSET such as 1MB here, this value should also be considered to calculate _end_of_ram.

2. Accessing invalid memory region

• As lk.bin is not just about the .text and .data segments. There are extra additional which are not counted as part of binary size but it is needed when loaded into RAM.
• It uses more address space and surpasses the _end_of_ram as there is no check regarding this which leads to access to invalid region.

Add a linker-time assertion to ensure that the final symbol address (_end) does not exceed the allocated RAM boundary (_end_of_ram). This prevents potential runtime memory corruption or undefined behavior caused by exceeding the available memory region, even when the binary file size appears to fit within the allocated space.

The issue arises because:

• The .bss section (zero-initialized data) occupies no space in the binary but is allocated in RAM at runtime.
• Stack space (e.g., __stack to __stack_end) consumes additional RAM.
• Sections are padded to align it to page boundaries (e.g., 4KB).

Without validation, such overflows may go undetected during build, leading to silent memory access violations during early boot especially on memory-constrained platforms.

Example:
_end = 0xffff000000184000
_end_of_ram = 0xffff000000174000 → ASSERT triggers, build fails

This change adds:
Error when _end > _end_of_ram

This ensures early failure during the build process, improving system reliability and debuggability.

[travisg]

Looks pretty good. At first glance it should only really matter on embedded targets since most of the MMU based targets will have a dynamic notion of what their memory size is, but in those cases the platform usually sets some sort of rasonable MEMSIZE that wont be exceeded at least at link time.

[vivek-jaluka]

I do agree with your point @travisg that MEMSIZE should be reasonable.

But, suppose we have a need to load LK on SRAM instead of DRAM which have memory constraint of 512KB.
In that, LK compiled for qemu-virt-arm64 generates a bin of 466KB but requires 528KB of memory in RAM.

From a developer perspective, it would be a good arrangement but it will create issues while booting showing abnormal behavior every time as adding any log or code will change lk.elf.map

It would be better if this can be checked in compilation time to prevent this issue in runtime. :)

[travisg]

can you see about the extra additions?

[vivek-jaluka]

Yes @travisg in that way, we may need to allot MEMSIZE considering KERNEL_LOAD_OFFSET as well which should be okay for the developer.

I have updated the patch.

[travisg]

Looks good! thanks