rgbds
rgbds copied to clipboard
gbdev
Smart linking
20:51 <@beware> anjbe_: is "smart linking" something you can do? smart linking means: only include things that are actually referenced
20:51 <@beware> this mostly helps with libraries
20:51 <@beware> as not all of the library has to be linked
20:51 <@beware> libraries tend to contain a lot of things a project doesn't need
20:52 <@beware> i think a linker could do this transparently
20:52 <@beware> (as in, as part of the linker)
20:53 <@beware> to resolve "is symbol X being referenced", you need to trace it from the program's entry point
20:53 <@beware> because a library can reference a symbol, but if that library is never used, then this reference doesn't mean it should be included
20:54 <@beware> anything (that has a symbol) that is never referenced is "dead" (as in, dead code, dead data)
This would certainly reduce a lot of ROM bloat, such as in Pokemon Crystal EN-US.
I'm not sure if this would be possible in all cases. Example:
SECTION "A", ROMX[$4000], BANK[1]
LABEL_A:
SECTION "B", ROMX[$4000], BANK[2]
LABEL_B:
SECTION "C", ROMX[$4000], BANK[3]
LABEL_C:
SECTION "D", ROMX[$4000], BANK[4]
LABEL_D:
SECTION "Code", ROM0
Function: ; a = Bank to read from
ld [$2000],a
ld a,[LABEL_A]
ret
But maybe for floating sections...
Just wondering, it wasn't documented anywhere and I installed a new IRC client recently.
toxa on gbdev Discord reports that dropping unused sections (those not reachable from -s entry_label) still isn't implemented in ISSOtm's rewritten linker.
This is not possible in general for non-floating sections, as AntonioND mentioned. People sometimes do write code that uses raw hex values for banks or addresses when they know what code/data to expect at those locations, so just looking at which labels are referenced wouldn't catch that.
There's also a case in pokecrystal where two data tables (for mon pics and Unown pics) are both orged to the same address in different banks, and only one label gets loaded into hl, but either table may be needed depending on which bank it switches to. And more generally, tricks like "I know hl == $4200 right now, so let's inc h to read the content I know is at $4300, which may not be referenced or labeled at all."
Perhaps floating sections could opt in to being left out if not referenced, like SECTION "Library Function Foo", ROMX, OPTIONAL, but even then the linker should print a notification if it gets omitted. (And any reference should count, whether it's ld hl, FunctionFoo or ld b, BANK("Library Function Foo") or dw FunctionFoo + 42.)
We could assign -s - (or something like that) to mean treat every non-floating section as an entry label.
Enabling a feature like this by default is downright insane; I don't think anyone was even proposing this. It's pretty clear something like this should only be enabled by a flag. Isn't there already a flag for this purpose (that perhaps doesn't work very well)?
@Rangi42 labels like those are trivial to reference with an assert, and in fact that's a good idea anyway. (Adding assert(PokemonPicPointers == UnownPicPointers) or whatever the labels are to pokecrystal would probably be a smart call.)
That being said, assemblers/linkers automatically discarding code and data from assembly input by default is still insanity, and I don't think anyone would want that to be the default.
@aaaaaa123456789 True, an assert would be ideal there (it falls under https://github.com/pret/pokecrystal/issues/706), but the code is valid without one, and a "smart linker" should not break it.
It seems to me that since this would be a section-based feature, putting OPTIONAL instead of BANK[$XX] at the SECTION declaration would be a convenient method, since it relies on the developer to be explicit that they're not relying on the section. Rather than a -s linker flag that has to judge for all the sections (or at least for the floating ones).
Maybe another section "kind", like we have SECTION UNION and SECTION FRAGMENT already?