Make RGBLINK usable in a C toolchain

[ISSOtm]

More needs to be done for RGBLINK to become a viable C toolchain linker, in order of importance:

• 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. Add a way to force two sections to be in the same bank #244 but in linker scripts)
• Linker script must be able to specify "optional" sections (i.e. reference sections but not error out if they don't exist)
• .cdb support
• Document how the SDCC and RGBDS worlds interact
• .lib support (ar archives, and lazily linking .os from those)
• .noi support (essentially .sym with 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 Ref line is not zero
  • Possibly check other flags for relocatable/PC-relative byte patches
• 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

[Rangi42]

Blocked by #1258

[Rangi42]

The goal is to implement floating and optional linker script sections for 0.7.0. (See the discussion starting in #rgbds-dev.)

[ISSOtm]

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.)

[ISSOtm]

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.

[Rangi42]

From bbbbbr in gbdev's #c-gbdk:

Not sure if the RGBDS object file support tracks this, or needs to track this, but the as of SDCC 4.4.0 the default SDCC object file format has changed from XL3 to XL4, meaning 32 bit addresses instead of 24 bit addresses

And, as of SDCC 4.5.0 the O Line in the object file format now includes the calling convention by default in addition to the platform. This is relevant because when there is a O line clash it can result in linker errors for older object files which didn't include the calling convention (even if a compatible calling convention was used). The solution is to omit the O line meta data which will avoid the error 😅 (with obvious side effect of not catching calling convention clashes). You can tell SDCC to do that on it's end with --no-optsdcc-in-asm

[Rangi42]

I don't have the expertise or interest in supporting this feature, and I haven't found anyone on the GBDK side either (neither in gbdev #c-gbdk nor in the GBDK server itself). Not closing this issue, but don't expect it any time soon unless someone steps up to even maintain the support we do already have.

[Rangi42]

Okay, XL4 is supported. We were already ignoring the O-line metadata. Still plenty of testing and TODOs left.