Better debugging

Collect here all your debugging-related wishes/requests/ideas from the Cloverleaf thread. Or from any other thread. Or from no thread. Just keep things on topic!

I’ll start by saying that recently I’ve been looking at getting hardware breakpoints & watchpoints (data breakpoints) working under RISC OS. Hardware breakpoints will be useful for placing breakpoints in ROM, or for other situations where patching in a breakpoint instruction would be awkward. Watchpoints will be useful for answering the perennial question of “who corrupted this data?”, which current debuggers can’t really do. In theory breakpoints & watchpoints are supported by everything ARMv5 and above, however I’ve run into some difficulties getting them to work on Cortex-A8, so it looks like there might be a couple of modern machines where we can’t support them.

One important item which will make hardware breakpoints & watchpoints truly useful is going to be the ability to single-step through code. This will be necessary for conditional breakpoints/watchpoints. The Debugger’s current single-stepper is woefully inadequate (and would probably fail in many situations even on ARM2), so if anyone wants to volunteer to implement a new single-stepper that would be great. Maybe there’s a decent open-source one we can drop in?

Excuse any typos. I’m using Chrome (ugh, but was looking at FlightRadar24) on the tablet…

Okay, some comments on what I’d like to see in a Debugger, and keep in mind that I have little experience of other systems other than VisualBasic.

• Ability to show all variables in scope (perhaps with an option restriction for local scope to keep things same). Display updates itself as the code is stepped through.
• As above, but for the underlying registers.
• Ability to automatically step over functions outside of logical workspace, so we step over CLib and SWI calls, not end up rummaging around in ROM or the RMA.
• Ability to debug module code. We know it is possible to fake an RMA, as Aemulor is able to run 26 bit modules, so perhaps a mechanism like that can be used to construct a module area for debugging purposes?
• Break when a variable changes. I think DDT is supposed to do that, but I never seemed to manage to get it to work. Your comments imply it might actually be broken?
• Drag the highlight of the currently executing line to resume execution from other lines within the same function (including restarting the function and yanking out of loops). Note – dealing with variables is up to the user. [with some exceptions around IfThen constructs, VB can do this, it’s useful for getting out of never-ending loops]
• Modify variables on the fly.
• Full trace maintained by the Debugger. Like a backtrace, but also records the state of variables as passed on entry…
• …and available at any time (perhaps a self-updating window)?
• Ability to run the program until the point where it crashes, and at that point will break into the Debugger to examine code, variables, registers etc.
  The primary distinction between this and DDT is that DDT terminates the program, leaving you to try to figure out what went wrong from the pieces. Do not terminate the program!
• Given its prevalence, it would probably be very useful to recognise a C pointer to flag up when it is accessed/used when its value is NULL.
• Ability to recognise RMA memory claims for modules, Dynamic Areas, etc, so can track what memory the code being debugged has legitimate access to (Wimp slot, RMA areas, DAs) so can break upon any accesses outside of these areas. Some, like reading memory blocks from the OS, are legitimate. Others, like an off-by-one overshoot of an RMA allocation, can be really hard to debug as you don’t know what you just accidentally trampled on, and when it is going to cause something to go awry.
• Most of all – doesn’t crash! ;-)

I think DDT is supposed to do that, but I never seemed to manage to get it to work. Your comments imply it might actually be broken?

I was talking about the Debugger module. DDT will have its own breakpoint/watchpoint/single-stepper implementation (perhaps they took one look at the Debugger and said “that’s terrible!”. Also there’s no programmatic API to most of Debugger’s features, so you can’t really use it as a backend to another debugger).

Given the number of comment about development tools in general and their cost I’d assume people want to aim for full debug support at zero cost.

So we already have DeskDebug from Niklaus Weiss (originally distributed by Spellings IIRC), and Vigil which was sold by APDL, again IIRC (who is the developer?).

Any opinions on or even better first-hand experience of those options?

@ Steffen Huber

So we already have DeskDebug from Niklaus Weiss (originally distributed by Spellings IIRC), and Vigil which was sold by APDL, again IIRC (who is the developer?).

AFAIK: I believe that DeskDebug is no longer being sold. Vigil seems now part of a Toolkit distributed by RComp and available on the !Store.

JFYI: Vigil is not a Debugger like DDT etc. It’s more like a WIMP based debug tool like the old MSDOS debug tool was. Sure we can use it combined with VERMA and other tools, but I think Vigil is more an analyser than a proper debugger like DeskDebug for instance.

@ Jeffrey Lee

My initial wishlist/requirements for Debugger would be:

- Capability to work in both CLI (text only) and WIMP mode (Desktop). I am a bug fan of the RISC OS Pico, so please let’s support more text based tools (I know Debugger works in CLI mode already, so this is just a note that you’re doing a great job there!)

- Capability to debug AIF, Modules and Libraries (aka being able to define entry points or trigger execution via SWI). I can do some tricks with DDT to test modules and libraries by creating stub code that calls them etc., but it’s pretty ugly and painful to use as well as limited. I know Debugger can read memory (Memory, MemoryA, MemoryI) but right now it seems that Debugger works more like the old MSDOS debug than a proper process debugger although if it does support breakpoints.

- Step In feature for Debugger (yes I know I can simulate it on the opcodes I am checking by adding multiple consecutive breakpoints, but something a little more “confy” would definitely make it easier :)

- Source level debugging support for Debugger please, ok I am being lazy here I know, but given that I only have weekends to play with RISC OS coding, source debug would definitely speed up debugging of my stuff and so buy me more time.

- Display variables and pointers values, Debugger right now seems to be ok only for ASM debugging, so can we improve it to support more higher level languages?

- Add Watchpoints for at least location addresses (but it would be better for variables and objects)

- Process/Task join, I know this can also be sort of simulated via memory analysis/breakpoints etc. in a raw way, but having it properly done would help a lot, otherwise I am forced to use DDT and the tricks mentioned above (and more).

- ELF support? This is a stretch-goal for me as we already have the UC Debugger, GDBServer on GCCSDK and we can also use (very painfully) QEMU GDBServer features to debug the entire RISC OS 5 stack on a simulated RPi2/3 / Omap3 which being bale to interface with VisualStudio (via GDB for VS), VS Code and CLion it’s still better than nothing.

I’ll add more later, thanks for tracking this! :)

AFAIK: I believe that DeskDebug is no longer being sold.

The Spellings shop closed some time ago, but IIRC Niklaus wanted to take over distribution himself, I’ll ask him.

• Ability to trigger a stack dump manually
• Print out environment (according to OS_ChangeEnvironment), perhaps with addresses *Where’d as appropriate

So we already have DeskDebug from Niklaus Weiss (originally distributed by Spellings IIRC)

I believe it relies on specific features of the Xscale processor. To get something close you’ll probably need JTAG. On the other hand, for a developer, to have two Pi (one JTAGed and one for control) is not a very big deal.

Didn’t Adrian Lees start working on one a while back?

See here http://www.sendiri.co.uk/udp.html and also here http://www.sendiri.co.uk/images/qdd.jpg

Desk debug seems to work with vrpc-dl ro 4 or 5.

I’d like to be able to ask Debugger via a SWI to set a breakpoint somewhere in the application slot, for a specified domain ID, and have it call me back when the breakpoint is reached.

@ Steffen Huber

The Spellings shop closed some time ago, but IIRC Niklaus wanted to take over distribution himself, I’ll ask him.

Cool, could I have a copy please? :)

(P.S. I have the required system, I believe it was the iyonix)

DeskDebug is specified as working on everything from RISC OS 3.5 upwards, so it is certainly not IYONIX specific.

@ Steffen Huber

DeskDebug is specified as working on everything from RISC OS 3.5 upwards, so it is certainly not IYONIX specific.

Brilliant, I have plenty of RISC OS devices post RO 3.5 (well actually also pre 3.5 lol), so the only question is how can we could have a copy of it? (paying for it of course!)

If it has already all the features we need it could be the quick answer to this issue.

Thx

I know that Niklaus is still alive and well and still has all the source code, but DeskDebug is written in 100% ARM assembler and applies many insanely clever tricks to do what it does. So we’ll see where we can get. Originally, DeskDebug sold for around 70 UKP/100 EUR, so it is unlikely to be released “for free”. And it would need some competent testers, because the variety of hardware to be properly tested has exploded compared to good old “RPC and IYONIX only”. I think it e.g. never worked in the A9home.

I’ll keep you updated. I think that, originally, Martin Würthner and David Ruck did a lot of testing for Niklaus to help making it more stable and useful. Maybe they are willing to comment?

@ Steffen

I’ll keep you updated.

Thanks a lot! :)

Happy to help debugging it if it’s needed. If it has never been tested on modern RPi and/or i.MX6 or Panda I have quite a few boards here running RO (included Pi1, 2 and 3, Pi Zero, Pico, Mini.M and ARMBook) so plenty of stuff to test things on. My limitation is mostly that I only have weekends to do RISC OS related stuff, due my daily job which is in software engineering for cyber security field, so pretty busy job nowadays lol.

applies many insanely clever tricks to do what it does.

I can but imagine.

I’ll stick my oar in the water if any testing is desired on an ARMv7 Pi2.

I think it e.g. never worked in the A9home.

Neither did RISC OS, really. <stir> <stir>

Somebody suggested that a debugger based on an emulator would be a good approach. Which makes me think if it would be easy to do such things on base of the RPCemu?

About DeskDebug:
I have tried to contact Niklaus by his website some days ago but no response so far. But I didn’t try yet the phone number.
About “not for free”. If my compaign will be successful and we have spare money left we ould finance to buy the source code from Niklaus. But that is in the stars until November.
But this makes sense only if DeskDebug is the solution we are looking for. Comprehensive and good handling.

I’m afraid only did a little bit of testing for Nik, as I do all my debugging on other platforms, and I didn’t have the patience to keep waiting for the Iyonix to reboot at the time.

I did give him a Cfront and G++ name demangler which wasn’t very good, Nik was always complaining about symbols in Techwriter it didn’t work for. I’ve since wrote a much better one, and sent him an email offering to produce a BASIC version of if for DeskDebug (it’s currently in C, C++ and C#), but I didn’t hear back. The offer still stands if you are in touch with him.

Strangely enough I emailed Niklaus about a week ago about DeskDebug, and he replied stating he was in hospital, so you might not get a quick reply…

I was wrong he replied but it landed in my SPAM.
Niklaus answer was:
Thanks for your report. Spelling closed its software distribution a few years ago. I wasn’t able to release a new version at the time. I didn’t have that much time anymore. David Ruck, who helped me a lot, no longer has time for RISC OS. I no longer have beta testers. That’s why I interrupted further development until further notice. The debugger runs on the RiscPC and the Iyonix with older operating systems .. I cannot network new devices like the Beagle Board and the Raspberry Pi with my other computers. So no tests are possible. I still have the source files. There are about sixteen thousand lines of handwritten ARM assembler lines. There are many tricks built in to make it work at all. I still don’t know how to go on.

The debugger runs on the RiscPC and the Iyonix with older operating systems

If it runs on the Iyonix, then it’s 32 bit friendly so that’s that hurdle cleared. One that might be a potential issue is if it rummages around in page zero. High vector builds have all that stuff elsewhere (and a better API for finding some of the info).
Asides from that, I guess the only other real issue is in the sorts of intructions that later ARMv7 and ARMv8 choke on. Namely bogus instructions (like an accidental write back to a register being loaded) and, of course, the infamous SWP(B).

I no longer have beta testers.

I do believe a bunch of us just volunteered.

I cannot network new devices like the Beagle Board and the Raspberry Pi with my other computers.

Hmm? I wonder why? When I first got the Beagle, I was able to pull stuff off the RiscPC by shoving a long network cable between the two machines. As I didn’t have ShareFS set up, I think I did something convoluted like run Samba on one machine and OmniClient on the other. It was dead slow, I wonder if the RiscPC would even be capable of maxing out a 10baseT connection, but it worked.

I still have the source files.

Brilliant, that’s the most important thing!

I still don’t know how to go on.

I won’t make any suggestions, as it’s your decision. However, remember that there are a number of people here… and I think you could count those who like using DDT on the fingers of one hand. :-)

I have ask Niklaus Weiss to join our discussion. I hope he will.