Crash Screen Updates

[someone2639]

• Implement remaining branch instructions ✅

• Implement COP1 instructions and syscall ✅

• Implement .sym format and n64sym tool from libdragon ✅

• File/line support as a result ✅

• Change font to something with lowercase and symbols ✅

• Move elements around to fill the whole screen ✅

• Arbitrary text coloring ✅

• Simple Overview page with only what's necessary ✅

• Implement break cache eret sync (Not sure if really necessary)

[arthurtilly]

can we also remove those stupid shadow instructions that appear behind the real ones. whats up with that

[gheskett]

can we also remove those stupid shadow instructions that appear behind the real ones. whats up with that

Probably just a meme with crash screen transparency and scrolling. Also that asymmetrical box drawing thing has been a thing for a century (though that should probably get corrected already, why is that still this broken...)

[someone2639]

Ready for Review!

• n64sym tool needs testing on other distros, since I run "/usr/bin/%s-addr2line" % $(CROSS), and I'm only 90% confident that works on everything
• Stack Trace and symbol exporting can be disabled, though I feel like disasm is important enough to stay (that's how it was in the old crash screen); This saved at least 300KB in the rom due to not even packing the symbol table in the ROM
• Since everything is guarded by a define, removed the if parse_map == MAP_PARSER_ADDRESS style lines and replaced them with ifdef's
• Color support in overview soon:tm:

[gheskett]

Will review the shiny new denser things later (and probably gloss over the copied libdragon stuff if you can point me to which is which)

[gheskett]

Also since we're touching it anyway, can we replace the HackerSM64 syscall with a proper trapping alternative? (Discuss with Falco on this probably, but even FORCE_CRASH would probably work well enough, plus that'd also remove the need of using a separate ASM file for assertions.)

[someone2639]

switching assert strategies seems like a rabbit hole since it's either a trap, break, or syscall depending on who you ask (it's even a break 0 in libultra technically)

[mpharoah]

The issue isn't using syscall, break, or teq $0, $0, the issue is that the crash screen is blindly trusting that memory set only in the HackerSM64 assert call is a valid pointer, and crashes if not, causing the crash screen to crash if the BREAK/SYSCALL happens from 3rd party code. Just need to validate that the pointers to the assert string have actually been set.

[someone2639]

That seems like an easy enough fix, though some time down the line (read: NOT IN THIS PR), we should come up with an ABI either here or in hackerlibultra where we can decide that e.g. break with specifically a value of 0 is a failed assert while break 6 isn't

[mpharoah]

Good idea. My suggestion would be SYSCALL 18995 (18995 being the 20 bits that give ASRT when base-32 encoded)

[someone2639]

Ready for another lap 🏇

[gheskett]

Code-wise, I think I'm good on this for now. That said, I've found some issues through playtesting:

---

1. The disasm seems to have an issue in which the functions disappear upon scrolling (see screenshot below for difference after scrolling down a singular entry). Notice the first instruction was skipped, and the other function name is gone. The instructions print one fewer lines than before.

---

2. The Puppyprint log page does not display correctly. It need to not re-render the background, and also prints bottom-up rather than top-down.

---

3. Some of the text alignments on the assert page (and also page 0) are still off. Ideally everything is monospace.

---

4. The crash screen seems to not be able to find audio code files (in this case, src/audio/synthesis.c). Notice also that the stack trace is incomplete and only displays two functions.

[someone2639]

Fixed spacing and the puppyprint visual bug. (Probably not going to fix the puppyprint log ordering, since that seems like an intentional feature, see here)

For the stack bug, I was able to get just before thread4_sound printed, but it did seem to skip that function, so I will go down the heuristic mines to investigate

[someone2639]

Ready for another lap 🏇

[gheskett]

Couple things:

1. I'm noticing the spacing is still off for some things, notably following File:
2. The synthesis stack trace still only goes back a couple functions (assuming this is still WIP)
3. The Puppyprint log should be displayed at the top. Puppyprint does indeed do this:

I suppose the text printing order is a thing, but I honestly don't like how it prints newest at the top anyway, so that should be addressed Puppyprint-side. The only consideration there would be excess messages printing above the top. Fixing this would be easy if Puppyprint can't do newlines, otherwise we'd have to newline count everything ahead of time to make a determination. Probably out of scope, I won't require the ordering swap for this PR (though you're welcome to implement it if you want).

[gheskett]

Okay I think I'm satisfied. The only thing I'm thinking now is that it might be a good idea to render 100% opacity on page swaps and render transparent only on the first render of the crash screen, since subsequent renders basically black out the screen already and just make text hard to read. Ideally we'd just cache the framebuffer here or something, but that's out of scope.

[gheskett]

DId some additional testing; the crash screen seems like it straight up does not work on console.

[gheskett]

I tried bisecting the (probably) crash, turns out this line seems to be the point of failure (or really, the IO_READ macro behind this function call). Absolutely no idea what's going on here though or how to fix it, so good luck :D

NOTE: No, it's not a null pointer exception with symt, but it may be possible that the IO_READ provided address itself is invalid. Worth noting also that the crash happens on the very first call to this function within the loop...assuming it's even a crash in the first place (yielded thread?)