.init_array section breaks linker_script.

[elfprince13]

Archiving Discord discussion for posterity:

@elfprince13: continuing last night's discussion - here's a diff of the assembly code between the version that broke the linker_script and a "fixed" version that moves the destructor execution into a block scope with automatic storage. The only thing that looks suspicious in here to me is the presence of the .init_array section which I haven't seen elsewhere. app_tool's linker_script makes mention of .init_array but maybe it's not fully / completely implemented? I don't see it anywhere else in my output assembly
asm_breaks_linker.patch

@calc84maniac: init_array is supposed to be handled in crt0

@elfprince13: as I understand it, crt0 "handles" it in the sense that it generates code which does the init stuff but is it possible app_tools isn't calculating where to place it in memory correctly and it's breaking some size calculation?
I'm not seeing anything else in that patch which plausibly looks like it could crash the linker

@commandblockguy: the initializer/destructor arrays are in their own linker section which isn't relative to anything
which breaks the relocations

@calc84maniac: so can the linker be told that it's relative to .text?
just like .rodata is
I mean, why doesn't .init itself have the same problem

@elfprince13: does any of the data need to be mutable / should it be relative to .data instead?

@calc84maniac: oh wait, I don't think .init_array is actually supposed to output any data directly...
the function pointers from it get placed in .rodata https://github.com/CE-Programming/toolchain/blob/079cb0d963fff596858c4ada096e6eb86202f5fb/src/crt/crt0.src#L48

@commandblockguy: right
but I can't apply relocations to stuff if I don't know where it ends up in the final binary

@calc84maniac: well that's the thing, it doesn't end up in the final binary

@commandblockguy: so I think you'd just need to get rid of the load and have it output the section directly

@calc84maniac: the functions that it contains need their relocation info after they've been inserted into a dl or call in a real section, but idk if that needs any special handling