SeriousErrorV

Been watching the CVS changes? Some interesting things going on with regards debugging aids and picking up symbols within the ROM image.

What I think would be extremely important is to be able to trace an application crash into CLib, because the current situation is “something happened here, and then it disappears into the library code someplace”, which can be difficult to work out what is actually happening.
If this change means we can tell that “something went wrong in my_func while calling _kernel_osword”, that would make a big difference to fixing borked applications.

Been watching the CVS changes?

Like forever. Well, for a few years anyway.

Some interesting things going on with regards debugging aids and picking up symbols within the ROM image.

Jeffrey did say he was going to add stuff, so if you want the feature and it isn’t too awkward I’d say he be inclined to do it.

If this change means we can tell that “something went wrong in my_func while calling _kernel_osword”, that would make a big difference to fixing borked applications.

You might have to stare at the dump for a few minutes to make sense of it (the Debugger produces an annotated stack dump, so it’s not quite as user-friendly as a stack backtrace), but yes that’s the general aim.

In lieu of me finding the time to write the docs, here are a few example dumps:

• ZeroPain log for an application passing a null pointer to fwrite: http://pastebin.com/7chLnGWu
• Debugger log for the Sunfish crash: http://pastebin.com/TTYR07La (that was produced from today’s autobuilder ROM, which is lacking the ROM debug symbols – my checkin to enable that was a bit late so it missed the build)
• ZeroPain log of an application passing a null pointer to a SWI: http://pastebin.com/uBRnA6Ka (slightly older code, ignore the bug that caused the last word of the SVC stack to go missing)
• ZeroPain log of doing SYS "OS_Find",&40 from BASIC: http://pastebin.com/sNYCJjRW (looks a mess due to there being several large buffers on the stack full of stale data, but from experience I can tell you that this is a million times better than having to unwind and annotate a stack dump manually)

There’s some room for improvement (especially with the output the Debugger produces), but it’s a lot better than having nothing at all.

If people want to see the output the Debugger produces for themselves, all they need to do is set Debugger$AnnotatedFile to a filename for the log to be saved under and then set Debugger$DumpOptions to -file annotated (and then find a program to crash).

Yeah, kind of hard to read, but even just following the function names up the dump is really useful.
I think I’ll need to bake myself a new ROM soon. Damn shame the monthly changes can’t be merged into an offline (non CVS) copy of the sources…

Full documentation is now up.

https://www.riscosopen.org/wiki/documentation/show/Debugger%20Exception%20Dumps