Memory Editor/Viewer

Hi there
Is there an App that allows you to view memory locations almost in realtime for RISC OS?
While doing C coding I have a need to check what is being stored adjacent to certain memory locations.

I want to track down what is overwriting my variables. Obviously an error on my part, but if would be much easier if visually see what and when it happens.

*memory

Displays the address you specify and some after . So give it a address lower than yours.

You might be able to use StrongED if it can grab the memory locations in question. This means that they need to be in application space, in a module or its workspace, or a dynamic area.

The Dump mode has a toolbar button that can be used to re-grab the data from memory. Clicking this button regularly might help you pin down when variables are overwritten.

If you grab the memory twice and then re-grab only one instance you’ll be able to compare before and after.

If you use Reporter you can try something like

void report_dump(int addr, int len, int width)
{
#define Report_Dump 0x54c86
os_regset regs;
regs.r[0] = addr;
regs.r[1] = len;
regs.r[2] = width;
os_swix(Report_Dump,&regs);
}

+1 for Reporter for keeping it simple.

You can also use the DDE debugger to watch memory locations and break execution when their contents change (at the expense of it executing very slooowly).

Thank you so much for the help. I’ve managed to use both the report_dump method using OSLib and the StrongEd Dump method.

I’ve tracked down where the error occurs, but it puzzles me.

I have my own struct that stores my window and icon data.
I call the OSLib xwimp_get_window_info and it returns no error.
The address location of my stuct window changes to a zero page memory location 16!

I must an error somewhere, but looks like I’ll be scratching my head for a while tracking it down. :-)

I must an error somewhere, but looks like I’ll be scratching my head for a while tracking it down.

The search term nobody’s mentioned (though Stuart got close) is ‘watchpoint’.

Breakpoints are pretty well known (from ARMv5 onwards there’s even a software triggered breakpoint instruction, BKPT), but a watchpoint will cause a debugging event when a certain pattern/width of load/store happens on some data. For example: a byte write to addresses &8000-&800F.

For this a hardware debugger is essential. Many boards have JTAG headers on them (I believe the Pi does bring out its JTAG somewhere, though I’ve never used it) and you’ll need a JTAG debugger (typically around £250) which is controlled from an IDE on the PC. ROOL have one for the Beagleboard which can be loaned out as I borrowed that to fix a gnarly printing bug a few years ago.

I notice though that part C of the v7 ARMARM describes that the CPU can see its own debug registers via the CP14 interface. It’d be a fun exercise for someone to see if the hardware watchpoints could be set up from RISC OS for the Debugger or DDT to use – then we could trap things like spurious writes as Alan wants to do without having to run it single stepping in DDT.

Wouldn’t it be nice to have an ARM equivalent to Beebug’s EXMON II debugger/tracer. I learnt so much about 6502 assembler from be able to trace what the program was doing one step at a time and seeing the registers and memory changing in real time. I used it to study software protection, often finding that cracking the protection was more fun than the game it protected.

I used it to study software protection, often finding that cracking the protection was more fun than the game it protected.

I have to agree on that. I’ve never had any interest in computer games except where there was a protection mechanism that I might “investigate”.