I'll put in a section for handling certain types of exceptions once my custom exception handler code matures more. Once ELF loading gets put in, debugging exceptions should be much simpler (I should be able to get a stack trace, filename/line number, register dump, etc.).
[EXE] on System Errors
Some system errors actually are handled by the OS in the error dialog with the [EXE] key. I was testing code and had a bad write (target was in the 0xFEC1nnnn area), causing an ADDRESS(W) error. Hitting [EXE] let the program continue running, although completely unstable with the RAM trashed. The full extent of this key should be examined more safely. -- Ahelper (talk) 04:39, 3 December 2014 (EST)
The string used for the system error dialog uses a formatting string that is compatible with printf and friends. This might be valuable to find the syscall related that generates that message content rather than including printf and friends in individual addins (or a shared library when ELF loading gets around to working). -- Ahelper (talk) 17:36, 3 December 2014 (EST)
- That is a very good idea, the sad part is that the printf/sprintf/etc. may not be exposed as syscalls, which means there's not a common way to call them across OS versions, like what happens with the zlib functions. However itoa, for example, is available, so it's really possible that sprintf is too. Would it even be possible that there's a more or less complete libc waiting for us, we just don't know the syscalls? I would think that by now we would have found about them... --Gbl08ma (talk) 19:18, 3 December 2014 (EST)