Crash Screen Updates by someone2639 · Pull Request #888 · HackerN64/HackerSM64

someone2639 · 2025-06-16T01:32:38Z

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 · 2025-06-16T05:54:09Z

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

gheskett · 2025-06-16T05:57:04Z

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 · 2025-06-24T01:59:13Z

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 · 2025-06-24T04:40:54Z

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 · 2025-06-24T11:23:40Z

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 · 2025-06-24T12:25:14Z

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 · 2025-06-24T12:49:41Z

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 · 2025-06-24T13:16:47Z

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

…xtbounds into crash_c1

someone2639 · 2026-04-28T03:26:51Z

Ready for another lap 🏇

gheskett · 2026-04-29T15:03:25Z

Final:tm: feature request: Add a Makefile flag that can override optimizations on everything and replace them with -O0. Additionally add an attribute for this in macros.h that can be applied to individual functions.

gheskett · 2026-04-29T15:08:03Z

Also a way to replace -g1 with -g2/-g3 since I think GDB wants that

…on attribute helper

someone2639 · 2026-04-30T02:26:00Z

Ready for another lap 🏇

gheskett

Well I hate to be the bearer of bad news, but...the crash screen is still crashing on my end.

someone2639 · 2026-05-19T03:15:51Z

Ready for another lap 🏇

gheskett · 2026-06-04T03:41:31Z

That did it, crash screen crash is gone. Will follow up with additional testing.

…ffer

someone2639 · 2026-08-23T22:12:40Z

Ready for another lap 🏇

arthurtilly · 2026-08-23T22:34:01Z

@claude review this

gheskett · 2026-08-24T01:09:48Z

 typedef struct {
    char *file;
-    char *func;
+    char func[64];


Is this safe for function names 64+ bytes long? Or does map packer handle this?

symt_string eventually handles the dma and only copies in the number of bytes that the buffer passed in can hold

it does not crash but i also couldve sworn i truncated these...

How safe are these uses of sizeof, given these are strings?

And for all similar functions/variables?

gheskett reviewed Jun 16, 2025

View reviewed changes

Comment thread src/game/mario.c Outdated

someone2639 changed the title ~~Crash Screen Disasm and Map Packer Updates~~ Crash Screen Updates Jun 17, 2025