DDT debug - Cummings and Goings

Been trying to find a way of stepping through graphics code printing to screen – tried a graphics window Prog -
with limited success.

Was trying DDT – found it would handle switches to SVC mode – and if you knew the address – you could step through module code.

One of it’s SWI seem to be able to start a debug – any info on using the SWIs directly?
[Edit]
Who wrote it – and is the ‘C’ source available?

It seems to be able handle short bits of code for testing purposes.

Very handy – set the file type – double click and away you go.

Pity you can’t save the option of ‘Display Regs’ and open the ‘Step’ window – Perhaps you can!

Some extra bits.

You can drag a !app onto
DTT on the icon bar Arm code or ‘C’ and it goes to work.
(For ‘C’ it is nice to know where ‘main’ Proc is) use ARMalyser.

Doesn’t like ‘Utility’ progs to be dragged on DDT icon bar – but excepts them if file typed to FF8

Doesn’t like ‘Utility’ progs to be dragged on DDT icon bar

That’s a pretty useless thing to do, Colin – Utility-type executables expect a particular environment different to that for Absolute executables.

When over a menu – moving pointer to the right – to open the next menu – is the action automatic to open the menu?

Who wrote it – and is the ‘C’ source available?

Acorn wrote it, and given its age I would expect that much (all?) of it is written in assembler.

Pity you can’t save the option of ‘Display Regs’ and open the ‘Step’ window – Perhaps you can!

I don’t think it can start up in a given state. It’s a shame, as it would be useful to be able to script its behaviour, like “load this program, wang a breakpoint onto this function, start running”. After all, when you’re debugging there’s probably somewhere specific you’re going to be looking at, so it would be good to be able to home in on that and not have to jump through a lot of hoops to get there.

Not to mention the extremely annoying “bug” where the debugger can either allow or fault memory accesses outside of application workspace. Given that a lot of the RISC OS API involves throwing memory blocks around (not to mention Dynamic Areas), this really needs to be broken into three: fault accesses outside of application space, fault accesses to invalid memory locations, allow anything.
For example, it is not currently possible to fault zero page accesses while allowing access to data in a block in the RMA.
One is supposed to happen, the other is a bug. ;-)

is the action automatic to open the menu?

As I understand it, DDT contains a big chunk of the RISC OS 2 Wimp code in order to implement its UI. This was intentionally never updated from the fugly look because it was considered a useful way to highlight that DDT does not use the Wimp, it provides something that behaves in a way similar to the Wimp. Auto-opening menus? That came in with RISC OS 3 didn’t it?

Doesn’t like ‘Utility’ progs to be dragged on DDT icon bar – but excepts them if file typed to FF8

I wonder, if you type a Utility as &FF8, where it’ll be stacking stuff? Utility programs have a specific set of entry conditions as mentioned by Stuart, so they won’t be expecting to have things like R13 not being set.
https://www.riscosopen.org/wiki/documentation/show/File%20formats:%20Utility

Going by ‘DTT’ using the ‘CLib’ – not that you can’t use that with BASIC or Assembly.

If your ‘Util’ needs a stack – provide one for testing :-)

With ref to my ‘menu’ problems – I double checked the pointers within the menu data.

I could get ’Display – Reg – with update working – but not displaying being able to show dis-Assembled code.

Breakset on SWIs stops the code at first contact with the swi from using ‘Continue’

Have used a dummy ‘SWI’ module to provide a swi marker – in code for it to stop at – where you want.

Trace seems to work – but stops when you use ‘Continue’ :-(

Any tips on using ‘DTT’ – would be useful :-)

Since SWIs don’t retain flag info – is there a way around this?

SwiEQ Beep
BEQ somewhere
Continue

How does a swi know where it returns to – is r14 stacked like BL

Branch with link.

Move the beep to “Somewhere”.

Explicitly save & restore flags (and a couple of temp regs, usually including r14) around your debugging SWI calls.

You could draw inspiration from the debugging macros in Export.APCS-32.Hdr.Global.Debug.

https://gitlab.riscosopen.org/RiscOS/Sources/Programmer/HdrSrc/-/blob/master/hdr/Debug

Remember that ARM doesn’t stack registers! SWI overwrites r14_svc (with a return address) just as BL simply overwrites r14.

Rick Murray wrote…

Acorn wrote it, and given its age I would expect that much (all?) of it is written in assembler.

Nope. It’s mostly C (~700K in c/h, ~170K in s), because writing a tool of any complexity should be in a high level language :-)

But that assembler is a bit exciting.

I don’t think it can start up in a given state.

A bunch of configuration for window positions and the like were added by Robin some years ago. Although this didn’t include the selection of breakpoints, watchpoints or whatever, etc, it was on our list to add. Pretty sure that this went back to Pace. Easiest way to check whether you’ve got the updated version – press tab in a dialogue that expects a symbol name and see if it completes it.

As I understand it, DDT contains a big chunk of the RISC OS 2 Wimp code in order to implement its UI.

Nope. The windowing implementation is in C, which implements a user interface which looks like the Wimp.

Justin: because writing a tool of any complexity should be in a high level language :-)
Computer Concepts: Hold my beer.

I wonder what is going on here!

Cmp r10,#&30
Add r0,r10,#&30
Subcs r0,r0,#&0A
SwiCS XOS_WriteI+"1"
Swi XOS_WriteC
SwiCC XOS_WriteI+" "
Swi XOS_WriteS

It’s worth pointing out that on the original ARM, flags were often preserved across SWIs (unless they specifically alter the flags) as the flags were a part of the preserved R14 (PC+PSR). This behaviour can’t be relied on any more (no implicit flag preservation), so the above code would need to be rewritten.

Sometimes converting code to 32 bit is simple, don’t ORR the V flag into R14, don’t try to restore flags on exit, etc.

And sometimes, sometimes you run into code like this. ;-)

This bit of code comes from the ‘DTT’ ‘C’ module – perhaps it is rarely used.

But am looking as so other Prog that has a whole row of swi’s – including BL^ :-)

Thinking along the lines -

Cmp r0,#2
Bne xxx
Swi Beep
Msr cpsr,#eq
.xxx

[Edit]
If you didn’t mind corrupting r14

BLeq somewhere
More code

.somewhere
Swi Beep
Msr cpsr_f,#EQ
Mov pc,r14

Is there a simple swi- that can be inserted into code – that waits until a key is pressed – before resuming?

SWI OS_ReadC ?

If you didn’t mind corrupting r14

But the SWI in somewhere will corrupt r14, so the MOV PC,r14 will mind.

If you are using the BASIC assembler, have you looked at the functions in Reporter for BASIC assembler debugging?

Should be in User mode – the idea was to put stops in the code and step through – seeing how the screen was being build up.

Though about enclosing that swi ReadC in a simple ‘swi Stop’ – saving the flags & Regs.

So it just responded to a key press.

Surely easier to just wrap SWI OS_ReadC in a local function that saves regs and flags? [Unless you are trying to use it in routines that haven’t preserved r14 or are using it as a temp register]

seeing how the screen was being build up.

Is this DDT again?

Shame. I had a problem with DDT ¹ which, I’m not sure what triggered it, but suddenly the entire thing ran like treacle and you could see the screen being built up. I probably should have videoed it, but I was too busy swearing at it.

Much more commonly (like all the time) I get the on-screen text suddenly becoming half height, and redraws can be quite wonky.

¹ Would be a newsworthy event if DDT didn’t screw up. :-p

Ideally I would like ArmDebug to be finished 32 bitted – it handles module code – Arm code in BASIC – being able to set it’s SWI in a module.

Since I converted some sound modules for RailPro

I thought !Dissi should be finished 32bitting.

Using ‘DTT’ & Deskdebug to debug it.

Have disassembled ‘DTT’ module – so if there is some test code – that upsets it!!

I might take a look!

Dissi has a built-in Sprite Area in the !RunImage – so is there any info on the setup of SpriteArea’s.

With ref to ‘DTT’ is ‘Lazy Task’ behaviour switched on or off in newer machines.

Did Robin Watts extras -passed to Pace -get added to the 32bit version of ‘DTT’?

is there any info on the setup of SpriteArea’s.

OS_SpriteOp 9 – Initialise sprite area

OS_SpriteOp 9 – Initialise sprite area

? I think he is asking about the format/layout of the sprite area.

It’s exactly the same as a sprite file, with the exception of the first word being inserted, giving the size of the sprite area. This is not necessary in the file, because the file size attribute provides that information.

It’s a short header (https://www.riscosopen.org/wiki/documentation/show/Format%20Of%20Sprite%20Area) followed by zero or more sprites (https://www.riscosopen.org/wiki/documentation/show/Format%20Of%20Sprite).

Daft question – what file type is Assembler – tend to use text here.