Debugger

Some things that would be nice to see in Debugger (listed in decreasing order of how much their omission bugs me ☺):

• “ADR Rx,...” followed by “ADD Rx” or “SUB Rx” → change the ADD or SUB to be “ADRL Rx, &xxxxxxxx” to the correct address.

• “STMDB R13!”and “LDMDB R13!” → “STMFD R13!” and “LDMFD R13!”.

• “SWI [X]OS_WriteI+xx” → “VDU xx”.

• “MOV R0, R0” → “NOP”.

• [optional] Can output register names (Rx form or APCS) in lower case? I don’t like lower case myself, but I’ve seen enough code like that to know a lot of people…do.

• Plus Debugger$Options extensions for the options implemented. ;-)

“ADR Rx,…” followed by “ADD Rx” or “SUB Rx” → change the ADD or SUB to be “ADRL Rx, &xxxxxxxx” to the correct address.

Adding it as a comment would make sense, but changing the disassembled instructions could lead to problems with some code. Consider:

.func_one
ADR R0,somewhere
.common
ADD R0,R0,#some_offset
...

.func_two
ADR R0,somewhere_else
B common

The debugger won’t know that the ‘common’ label exists, so any attempt to convert the ADR+ADD at the start of func_one into an ADRL will break func_two.

“MOV R0, R0” → “NOP”.

ARMv7 has a NOP instruction (which I think is an undefined instruction on earlier architectures?), so although assemblers may treat NOP as an alias for MOV R0,R0, attempting to perform the same transformation in reverse would be wrong as it would result in disassembly that isn’t guaranteed to result in the same binary when re-assembled.

I second Rick. I was debugging some code earlier and getting very frustrated constantly having to convert things in either BASIC or on a calculator, some of these QoL suggestions would have made the code a lot clearer. They should go in the comments though as Jeffrey suggests, so the code is an accurate representation. A few more suggestions:

1. xxxNV R0, R0 ; NOP (ARMv1..v3 26bit) / Undefined instruction
2. Show all constants in hex, rather that the current bipolar mix of hex (ADR, B, BL etc) and decimal (offsets in LDR/STR), eg LDR R0,[R1,#&20] ;=32
3. Show the actual value of rotated constants, eg MOV R0, #&80,26 ;=&00002000
4. Show the actual address of an offset LDR/STR following an ADR, eg

ADR R0,&00010000
LDR R1,[R0,#-&0C]     ;=&0000FFF4

changing the disassembled instructions could lead to problems with some code

There’s already a good example of this type of confusion in the Debugger:

10000 : .... : E28FF014 : ADR PC,&000101C

Instead of:

10000 : .... : E28FF014 : ADD PC,PC,#&14      ;=&0001001C

Using !Zap ARM module/FF8 – If I remember! – you would see:-

adr r0,&1000
add r0,r0,#0

Clicking on ‘adr’ in the !Zap window – and then the right arrow key – it would take you to &1000 – very useful.

Pity something like that couln’t be implemented for use in a Text’ file – Rick had a go in his Windows RO file viewer.

Show the actual value of rotated constants, eg MOV R0, #&80,26 ;=&00002000

Spent another day yesterday with two laptops on my lap, manually working out constant value output from Debugger 😡

Another useful QoL improvement, would be a scrollable Debugger where you can move around memory and follow branches etc, like Zap/StrongEd.

Clicking on ‘adr’ in the !Zap window – and then the right arrow key – it would take you to &1000 – very useful.

I think StrongEd supports this as well, it certainly works for branches. Not sure I’ve tried an ADR yet.

Ref begining of thread.
Zap used to do this.

adrl r0,&xxxxx
sub r0,r0,#0

&xxxx moved to value by using right arrow key.

[edit 1]
Instead of doing:

adrl r0,#&xxxxx
sub r0,r0,value

Where you work out what the pointer value was.

Spent another day yesterday with two laptops on my lap, manually working out constant value output from Debugger ?

It’s something I’ve looked at for StrongED but have been putting it off in the hope it would be added to Debugger.

Another useful QoL improvement, would be a scrollable Debugger where you can move around memory and follow branches etc, like Zap/StrongEd.

The addresses you’re looking at can’t be grabbed by Zap/StrongED?

I think StrongEd supports this as well, it certainly works for branches. Not sure I’ve tried an ADR yet.

Yes, StrongED will follow ADR on right arrow key (4.70a13 will also follow ADRL), PC-relative LDR/STR can also be followed.

been putting it off in the hope it would be added to Debugger

It’s certainly a change that’s required in the Debugger as its currently really inconsistent. For example:

E3A00D10 MOV R0,#&400

Debugger reports this as:

E3A00D10 MOV R0,#&10,26

However,

E3A00D11 MOV R0,#&440

is reported as:

E3A00D11 MOV R0,#&440     ; =1088

If the Debugger is trying to report exact encodings, both of these should be reported as:

MOV R0,#&XX,<shift>    ;&ZZZZZZZZ =DDDDDDDD

Of course there’s also the glaring issue with use of pseudo instructions:

ADD PC, PC, #16

being reported as:

ADR PC, &XXXXXXXX

The addresses you’re looking at can’t be grabbed by Zap/StrongED?

No, the machine is in a single tasking mode. I do however dump memory and use StrongEd when I’ve located the code, but it obviously doesn’t help with the unintuitive output Debugger shows for constants.

If the Debugger is trying to report exact encodings, both of these should be reported as:

It appears that the different way of displaying immediate constants is by design. If the value is encoded with the lowest possible immediate + shift then the actual value is shown. If this is not the case, ie immediate has bottom two bits clear, then #&xx,yy is used.

E3A000B01  MOV,R0,#&400
E3A000C04  MOV,R0,#&04,24
E3A000D10  MOV,R0,#&10,26
E3A000E40  MOV,R0,#&40,28

Here’s the relevant bit of code from Debugger 2.02

00002F78 : E3A0A023 : #  ã : MOV     R10,#&23           ; ="#"
00002F7C : E4C0A001 : A Àä : STRB    R10,[R0],#1
00002F80 : E1A023A4 : ¤# á : MOV     R2,R4,LSR #7
00002F84 : E202201E : ^ Bâ : AND     R2,R2,#&1E         ; =30
00002F88 : E20480FF : ÿ€Dâ : AND     R8,R4,#&FF         ; ="ÿ"
00002F8C : E1A08278 : xŵ á : MOV     R8,R8,ROR R2
00002F90 : E1B0E428 : (ä°á : MOVS    R14,R8,LSR #8
00002F94 : 1A000002 : B@@Z : BNE     &00002FA4          ; <--- B &00002FAC
00002F98 : E3320000 : @@2ã : TEQ     R2,#0
00002F9C : 1A0001CA : ÊA@Z : BNE     &000036CC
00002FA0 : EA000001 : A@@ê : B       &00002FAC
00002FA4 : E3140003 : C@Tã : TST     R4,#3
00002FA8 : 0A0001C7 : ÇA@J : BEQ     &000036CC
00002FAC : E358000A : J@Xã : CMP     R8,#&0A            ; =10
00002FB0 : 3A000014 : T@@: : BCC     &00003008

If you RMfaster Debugger and change the indicated branch using MemoryA then it should always output the actual value.

It appears that the different way of displaying immediate constants is by design.

Correct – the ARM ARM stipulates that the “preferred” encoding (I.e. the one that assemblers/compilers should produce by default) is the one which has the smallest possible rotation value, and disassemblers should disassemble to the #xx,rr form whenever an instruction is encountered which is using the non-preferred form.

So changing the disassembly of the instruction would be naughty, but adding a comment which shows the expanded 32bit value should be fine (and maybe also a hint for the carry flag value – since #xx,rr is sometimes used explicitly in order to force a specific value)