Linker script and the stack(s)

[jmaargh]

I'm pretty noobish when it comes to linker scripts, but there are a couple of things that concern me about the one currently in the template directory.

1. I see nothing about stacks. From GBATek, I understand that there is the "user stack" (for when the CPU is in system mode) at 0x03007f00 in iwram, and the IRQ stack (for when the CPU is in IRQ mode) from 0x03007fa0 to 0x03007f00.
2. Further the BIOS expects all of 0x03007f00 to the end of iwram to be reserved for its usage
3. I don't see where BSS is zeroed out anywhere, is the BIOS guaranteed to zero out iwram for us?

Again, I don't fully understand linker scripts, but shouldn't there be some way of "reserving" iwram space for this? Clearly any custom iwram allocator would have to avoid the bottom of IWRAM, but also don't we need to tell the linker not to put anything from .bss there?

[corwinkuiper]

1. I don't think the linker really needs to know where the stack goes. Anyway, the stack positions are initialised by the bios.
2. The bios places the user stack before that, and the stack grows downward.
3. BIOS zeros out the RAM.

The answer is that we don't try. We probably could make the linker realise that it's overrun into the reserved area, but we didn't. In fact, we don't bother trying to prevent the allocator smashing the stack or the stack smashing the heap. You can easily smash the heap by infinitely recursing. A solution would be to have a smaller sized stack and invert the position of the heap and stack, but as I've not run into issues here I'm inclined to not bother as I would then have to choose a reasonable stack and heap size whereas now I don't have to decide.

By default, we put things in ewram (global alloc is ewram, statics are ewram).
I'm not sure why it was decided bss should go in iwram, I imagine it was because when we initially wrote this we defaulted to iwram but then decided against that and moved to ewram but forgot about bss.

[jmaargh]

Thanks, really helpful.

Good to know that BIOS zeroes out ram. I don't suppose you have a reference on hand for that? I couldn't find it in GBATek just now (though I may just being blind).

I've been writing my own GBA stuff from scratch and this project has been really useful as a reference for some of the stuff I don't know so much about (such as linker scripts). I was turned onto this issue when I had a problem with my interrupt routine overflowing the IRQ stack into the system stack (turns out in debug mode rust can EAT stack space).

I guess you should at least configure the iwram allocator to stop at 0x03007eff rather than 0x03008000 (maybe even earlier to give a little user stack headroom. But you're right that something more elaborate is probably diminishing returns.

If I ever decide to see what could be done by moving the user stack to a fixed size the bottom of iwram I'll let you know. Might be possible to get "cleaner" errors on a stack overflow that way, if the processor has features to support that.

[corwinkuiper]

I got the zeroing from tonc, https://coranac.com/tonc/text/hardware.htm contains "The various RAM sections (apart from Cart RAM) are zeroed at start-up by BIOS.".

The gba doesn't trap, it will execute instructions forever, illegal or modifying parts of ram that don't exist or not it won't stop. Mgba can be configured to trap, I believe.

I don't know where I first read about putting the stack first, but I found this gist which has some ideas https://github.com/japaric/embedded-in-rust/blob/master/content/stack-overflow-protection.md

I wouldn't recommend using no optimisations (which debug mode is by default), for embedded use at least opt-level 1. We use 3, apparently. Rust generates a lot of code, very nested code, that needs to be inlined and properly register allocated to produce something reasonable.

[jmaargh]

Oh, of course using zero-optimisations is going to bite me eventually, but it's very useful for debugging on mgba while test programs continue to run fast enough. In this case it even helped reveal an issue I didn't know about -- which is great! Moving all function calls to after the switch to system mode was trivial when I knew that was what was happening.

Thanks for the references, really good stuff :)