From ec5f45d2b3ee89dda5b5abd447a4f0e293d43341 Mon Sep 17 00:00:00 2001 From: dogruis Date: Fri, 22 May 2026 14:07:53 +0100 Subject: [PATCH] Assert rom_backup_data_address stays within RAM at link time Setting rom_backup_data_address to an invalid value (below ORIGIN(RAM) or past ORIGIN(RAM) + LENGTH(RAM)) currently produces a working ELF whose runtime accesses to .bss.bram silently corrupt memory. Two ASSERTs catch the misconfiguration at link time without changing behavior for valid placements. --- runtime/ngdevkit.ld | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/runtime/ngdevkit.ld b/runtime/ngdevkit.ld index 52f2fd1..e17095c 100644 --- a/runtime/ngdevkit.ld +++ b/runtime/ngdevkit.ld @@ -133,6 +133,16 @@ SECTIONS { * reference is not resolved properly by the MEMORY command */ rom_backup_data_address = DEFINED(rom_backup_data_address)? rom_backup_data_address : 0x100000; + + /* Catch overridden backup-RAM placements that would land outside the + * 60 KB of m68k work RAM. Without these guards, ld would silently lay + * out .bss.bram at whatever address was given and the runtime would + * read/write garbage on access. */ + ASSERT(rom_backup_data_address >= ORIGIN(RAM), + "rom_backup_data_address is below RAM origin (0x100000)") + ASSERT(rom_backup_data_address + LENGTH(BRAM) <= ORIGIN(RAM) + LENGTH(RAM), + "rom_backup_data_address + BRAM length (0x1000) extends past RAM end") + .bss.bram rom_backup_data_address : SUBALIGN(0) { *(.bss.bram) . = ALIGN(4);