rgbds
rgbds copied to clipboard
Make RGBLINK usable in a C toolchain
More needs to be done for RGBLINK to become a viable C toolchain linker, in order of importance:
- [x] Linker script must be able to specify floating sections (SDCC "floating" areas do not convey any "type" info, so the linker script must specify whether they are ROM0, ROMX, etc. but that shouldn't force their location.)
- This is half-supported; we have floating section addresses within banks, but we also want floating banks common to all their subsequent sections (i.e. #244 but in linker scripts)
- [x] Linker script must be able to specify "optional" sections (i.e. reference sections but not error out if they don't exist)
- [ ]
.cdbsupport - [ ] Document how the SDCC and RGBDS worlds interact
- [ ]
.libsupport (ararchives, and lazily linking.os from those) - [ ]
.noisupport (essentially.symwith a different format)
These smaller points cover TODO comments in the source code, marking partial support for, or incomplete understanding of, something checked off above:
- In src/link/sdas_obj.cpp:
- [ ] Handle
;!FILE [...]on the first line - [ ] Hard error if the rest of a
Refline is not zero - [ ] Possibly check other flags for relocatable/PC-relative byte patches
- [ ] Handle
- In test/link/sdcc/good/script.link:
- [ ] Investigate the
"_GSINIT"ROM0 section ("reportedly internal to the crt0") - [ ] Identify what the
"_DABS (ABS)"WRAM0 section is
- [ ] Investigate the
Blocked by #1258
The goal is to implement floating and optional linker script sections for 0.7.0. (See the discussion starting in #rgbds-dev.)
I think we should have both ROMX FLOATING for "floating bank", and ROMX 42 \n FLOATING for "floating address" (mirroring ORG's usage), so that the two feature sets are orthogonal. (I don't like just ROMX making the bank floating, I think it's too easy for it to be a mistake, especially for auto-generated scripts.)
The semantics of ROMX FLOATING actually kind of suck, because then all assignments in the section have to start somewhere. More useful semantics would be obtained by instead placing all "fully constrained" sections from the object files, processing the linker script (and FLOATING sections would be immediately placed wherever available), and then running the full placement routine with everything remaining.
But that's a lot more work, so I'd like to defer the implementation of that to a later version (probably in the Rust port anyway lolololo) and "only" implement FLOATING addresses. That would significantly hinder integrations, but I think it should enable some early but nonetheless valuable experimentation.