Locating crashes in ROM - going from address to code

My apologies if there’s a page on the Wiki for this. I had a look around but couldn’t find one.

I’m currently porting RISC OS 5 to the Bush Internet TV set-top box, and I’m having issues with crashes in wild and wonderful places in ROM. At the moment they’re mostly in modules, like this one:

mod init (kbdscan) done
POR detected
ReadDefaults
InitHostedDAs
MouseInit
ModuleInit
init mod WindowManager
init mod TaskManager
init mod Desktop
init mod SharedCLibrary
init mod ScreenModesError: DataAbort:Abort on data transfer at &FC1740CC (Error Number &80000002)
*rmreinit ScreenModes
Error: Abort on data transfer at &FC1740CC (Error Number &80000002)
*where FC1740CC

File ‘where’ not found (Error number &D6)
*rmreinit Debugger
Error: Abort on data transfer at &FC1B4240 (Error Number &80000002)
*

Is there a good way to take this crash address and pin it down to a specific line of code?

Thanks
Phil

You have *Modules and *ShowRegs will give you R12 aka the Guilt register to pin down the module. Other than that, good luck!

Sadly ShowRegs doesn’t work unless the Debugger module has been loaded first … and in this case ScreenModes loads far before Debugger.

The module init gives away that ScreenModes was responsible, but if it wasn’t clear, there is a way to look that up if you built the ROM from source and kept the log: look up the address in the ROM layout map that the ROM linker spits out.

For single-file or “include all” assembly modules it’s comparatively easy to get back to a line of code:

• Information gathering
  • Note down the fault address and cause from the error message.
  • Do the usual *Where and *ShowRegs on the target to get the system state.
  • Identify the guilty module
    • Run *Modules on the target if you can, and look up the module start address and length.
    • //ROM modules only//: Open the ROM build log with a text editor (in RiscOS.BuildSys.Logs, match it against your ROM filename). Look for the heading “Summary of linked ROM contents...” near the end. Try to find the fault address in the table (start address and length) below that.
    • For both methods you want to find the //largest// start address which is //less than// the fault address.
  • Subtract the start address from the fault address to get the fault offset.
  • Sanity check: make sure the fault offset is less than the reported module length.
• The GPA file method – the most reliable, where available.
  • Open RiscOS.Install.ROOL. Open the subdirectory for your current build type, and find the module you identified above. Alongside the module, you should also find a _gpa or _sym file.
  • Open the _gpa file in a text editor. Look up the fault offset in the address/line tables to get the line number.
  • Scroll up until you see a file header – this will tell you which file to look at.
• The DecAOF method – better than nothing but won’t work on e.g. the Debugger module. (but strangely works fine for e.g. PortMan)
  • Find the fully-linked object file and use DecAOF to dump it. Redirect the output to a file because it’ll be pretty big.
  • Open the text file and look up the offset. Again scroll up to find the header text, this should identify the source line.

I was trying to use the DecAOF method to debug the Debugger module last night. For some reason looking up the offset in the DecAOF output didn’t work, in the sense that the fault offset was greater than the AOF offset, but still within the module. I think that process needs a bit of refinement but it mostly-works for simple modules and is better than nothing!

If you use StrongED watch out because the line numbers don’t account for text folding! (I miss Zap) Unfold the whole file before scrolling to the given line.

The Debugger module can create exception dumps: https://www.riscosopen.org/wiki/documentation/show/Debugger%20Exception%20Dumps
But sadly this doesn’t really work for debugging the start-up process. Which is a shame because the annotated dumps (if they were dumped to the screen or HAL DebugTX) would be very useful indeed!

Sure that Debugger used to be very early in the list in ye olden days… Whose daft idea was it to try and stick stuff in the ROM in sort-of-alphabetical order.

And to echo what Stuart said… why the heck is the WindowManager before anything else? It is a very high level module and should probably appear a long way down the initialisation list.

In fact I’ll bet that’s probably part of what’s wrong here – many of the modules were unhappy if they didn’t have a messages file present. And none of FileSwitch, ResourcesFS, Messages or MessageTrans have initialised. Whilst they should work just fine without them, many do not.

Well, it looks like ScreenModes doesn’t need to a Messages file (https://gitlab.riscosopen.org/RiscOS/Sources/Video/UserI/ScrModes/-/blob/master/c/ScrModes#L1920) but it’s always possible that the SharedCLibrary does, and is failing. Or that one of the other parts of the system being missing is causing it to fail. Like FPEmulator, maybe.

That said, I can initialise older versions of those modules without any problem, so I presume it’s a little more involved than just missing some modules….

charles@phonewave ~/projects/RO/pyromaniac (report-error-vdu-experiment↑1)> ./pyro.py --config memorymap.zeropage_enable=true --load-module modules/SCL,ffa --load-module modules/ScrModes,ffa --config modules.unplug=MessageTrans --list-modules
Number : Address  : Private  : Name
------ : -------- : -------- : ----------------
  0    : 03800404 : 07000034 : UtilityModule
  1    : 0700013c : 00000000 : SharedCLibrary
  2    : 0701751c : 0701ac7c : ScreenModes
charles@phonewave ~/projects/RO/pyromaniac (report-error-vdu-experiment↑1)> 

I’d ensure that you have Debugger early in the list so that you can work out what’s wrong. And put your filesystems in there first. Even chuck Where into ResourceFS so that you’ve got something to help you in addition to Debugger.

The Debugger module can create exception dumps: https://www.riscosopen.org/wiki/documentation/show/Debugger%20Exception%20Dumps
But sadly this doesn’t really work for debugging the start-up process. Which is a shame because the annotated dumps (if they were dumped to the screen or HAL DebugTX) would be very useful indeed!

You can change dumps to be enabled by default by changing the value of DumpOptions_Default in s.Debugger. You won’t be able to get it to dump to file (there’s no code to set the default value of the Debugger$*File variables) but you can get it to dump to HAL_DebugTX.

Another tool which might be useful is my fiqprof/profanal – the analysis tool (profanal) can load most of the symbols from a build tree, allowing you to do address-to-line lookup of ROM locations, e.g.:

* profanal
> loadrom <build$dir> <build$imagename>
> info FC1B4240

I use a bash script that find the right line of source most of the time.

show_ro_code