Hi,
I was told about an issue with our romstage handling, as the linker happily links in global variables (with addresses in ROM).
That obviously doesn't work for writable values, but is a silent error (until things _really_ go wrong on runtime), so I looked for a way to break coreboot at build time in such a scenario.
Two possible solutions, both need to be added to src/arch/i386/init/ldscript_fallback_cbfs.lb:
1. _bogus = ASSERT((SIZEOF(.bss) + SIZEOF(.data)) == 0, "Do not use global variables in romstage");
This one looks for the size of .bss and .data (initialized and uninitialized globals) and breaks the build if it finds any. It doesn't tell, which global variables are involved.
2. Add .bss and .data to /DISCARD/.
That way, the linker complains about "missing" symbols (as they were discarded), but only if they were used by any surviving code. This means, it's no problem that the global is defined. If you use it later-on, it "mysteriously" breaks. The error message is rather cryptic, too: `variable' referenced in section `.rom.text' of coreboot-builds/kontron_986lcd-m/mainboard/kontron/986lcd-m/crt0.initobj.o: defined in discarded section `.data' of coreboot-builds/kontron_986lcd-m/mainboard/kontron/986lcd-m/crt0.initobj.o collect2: ld returned 1 exit status
I tend to prefer the first option, but it doesn't give _any_ clues which variable is responsible (except for "look for globals"), but at least it does tell the user what the real problem is.
Opinions?
There might also be a good opportunity for some naming cleanup: Rename and move ldscript_fallback_cbfs.lb to src/arch/i386/coreboot_rom.ld. Or better call it "romstage.ld" (and adapt coreboot_ram.ld in arch/i386 in the same way)?
Regards, Patrick