hatari debugger disassembly format changes

[TheNameOfTheGame]

Haven't used the debugger in a few months so I'm not sure what happened, but disassembler output from the debugger now looks quite different. Am using hatari v2.5.0-devel (Dec 19 2022).

In the past (I think it was with v2.3.1) I would get output such as this:

Code: Select all

000125e8 13e8 0008 0001 29ca      move.b (a0,$0008) == $00000008 [02],$000129ca [00]
000125f0 13e8 0007 0001 29d0      move.b (a0,$0007) == $00000007 [30],$000129d0 [00]
000125f8 13e8 0003 0001 29c3      move.b (a0,$0003) == $00000003 [62],$000129c3 [00]
00012600 0c28 0002 0003           cmp.b #$02,(a0,$0003) == $00000003 [62]
00012606 6408                     bcc.b #$08 == $00012610 (T)
00012608 13fc 004c 0001 665a      move.b #$4c,$0001665a [46]
00012610 43fa 4292                lea.l (pc,$4292) == $000168a4,a1
00012614 d3fc 0000 8000           adda.l #$00008000,a1
0001261a d3fc 0002 bf20           adda.l #$0002bf20,a1
00012620 b83c 0002                cmp.b #$02,d4
00012624 660a                     bne.b #$0a == $00012630 (T)

This was helpful since I could see the branch targets and various value resolutions.

Now the output is like this with both the "-disasm ext" or the "-disasm uae" options:

Code: Select all

00000150 48E7 78FC                movem.l d1-d4/a0-a5,-(a7)
00000154 0C28 003A 0001           cmp.b #$3A,(a0,$0001)
0000015A 6602                     bne.b #$02
0000015C 5488                     addaq.l #$02,a0
0000015E 2849                     movea.l a1,a4
00000160 2448                     movea.l a0,a2
00000162 43FA 0136                lea.l (pc,$0136),a1

As you can see, the output listing is missing the extra information from the previous example. How do I get the old disassembler format back?

I see this in the terminal window when I start hatari up:

Code: Select all

Selected external disassembler.
Disassembly output flags are 0x7.
INFO : Hatari v2.5.0-devel (Dec 19 2022), compiled on:  Dec 19 2022, 09:14:59

Code: Select all

Selected UAE CPU core internal disassembler.
Disassembly output flags are 0x7.
INFO : Hatari v2.5.0-devel (Dec 19 2022), compiled on:  Dec 19 2022, 09:14:59

Is my issue with the "Disassembly output flags" shown above? How would I change them?

[czietz]

The UAE disassembler default was perceived by many as too cluttered. Therefore, you can now configure the output as shown by "hatari --disasm help":

Code: Select all

Disassembly settings:
        uae - use CPU core internal disassembler
              (better instruction support)
        ext - use external disassembler
              (nicer output)
        <bitmask> - disassembly output option flags
Flag values:
        0x01: ext: no space after comma in the operands list
        0x02: opcodes in lower case
        0x04: register names in lower case
        0x08: ext: stack pointer as 'SP', not 'A7'
        0x10: do not show 16-bit words at this address
        0x20: uae: show EA + CC values after instruction
        0x40: uae: hex numbers in lower case
Current settings are:
        --disasm uae --disasm 0x66

I think, "--disasm uae --disasm 0x66" should give the output you expect.

[TheNameOfTheGame]

Thanks for the information. I tried the command switches you mentioned and it seems hatari picked them up.

Code: Select all

Selected UAE CPU core internal disassembler.
Disassembly output flags are 0x7.
Changed CPU disassembly output flags from 0xf to 0x66.
INFO : Hatari v2.5.0-devel (Dec 19 2022), compiled on:  Dec 19 2022, 09:14:59

But the disassambly listing in the debugger stayed the same and didn't go back to the old output format.

I am confused by what hatari is saying in the text above. It states "Disassembly output flags are 0x7" but then says on the next line "Changed CPU disassembly output flags from 0xf to 0x66". So there are "Disassembly output flags" and "CPU disassembly output flags"?

[czietz]

For me, the output looks like the one you expect (I think).

Code: Select all

czietz@NotebookHP:~/hatari$ ./src/hatari --disasm uae --disasm 0x66
Selected UAE CPU core internal disassembler.
Disassembly output flags are 0x7.
Changed CPU disassembly output flags from 0xf to 0x66.
INFO : Hatari v2.5.0-devel (Dec 27 2022), compiled on:  Dec 27 2022, 13:27:07

[...]

----------------------------------------------------------------------
You have entered debug mode. Type c to continue emulation, h for help.

CPU=$e1de1e, VBL=254, FrameCycles=64, HBL=0, LineCycles=64, DSP=N/A
00e1de1e 4e72 2300                stop #$2300
> d
(PC)
00e1de1e 4e72 2300                stop #$2300
00e1de22 46c0                     move.w d0,sr
00e1de24 4e75                     rts  == $00e2cf18
00e1de26 4e72 2400                stop #$2400
00e1de2a 46c0                     move.w d0,sr
00e1de2c 4e75                     rts  == $00e2cf18
00e1de2e 4e72 2500                stop #$2500
00e1de32 46c0                     move.w d0,sr
00e1de34 4e75                     rts  == $00e2cf18
00e1de36 4e72 2600                stop #$2600
00e1de3a 46c0                     move.w d0,sr
00e1de3c 4e75                     rts  == $00e2cf18
00e1de3e 4e72 2700                stop #$2700
00e1de42 46c0                     move.w d0,sr
00e1de44 4e75                     rts  == $00e2cf18
00e1de46 302f 0006                move.w (a7,$0006) == $0000a88a [bc3a],d0
00e1de4a d040                     add.w d0,d0
00e1de4c c1ef 0004                muls.w (a7,$0004) == $0000a888 [0000],d0
00e1de50 81ef 0008                divs.w (a7,$0008) == $0000a88c [0001],d0
00e1de54 6b06                     bmi.b #$06 == $00e1de5c (F)
00e1de56 5240                     addq.w #$01,d0
00e1de58 e240                     asr.w #$01,d0

I agree that there is something confusing with the initial flags being reported as 0x7 and then as 0xf. No idea, maybe the Hatari developers need to have a look.

EDIT
You could try displaying the current settings from within the debugger to make sure that they're being applied correctly:

Code: Select all

> setopt --disasm help
Disassembly settings:
        uae - use CPU core internal disassembler
              (better instruction support)
        ext - use external disassembler
              (nicer output)
        <bitmask> - disassembly output option flags
Flag values:
        0x01: ext: no space after comma in the operands list
        0x02: opcodes in lower case
        0x04: register names in lower case
        0x08: ext: stack pointer as 'SP', not 'A7'
        0x10: do not show 16-bit words at this address
        0x20: uae: show EA + CC values after instruction
        0x40: uae: hex numbers in lower case
Current settings are:
        --disasm uae --disasm 0x66

[TheNameOfTheGame]

Thanks for the suggestion. It's weird though, entered the command and it reports the flags as 0xf still.

Code: Select all

> setopt --disasm help
Disassembly settings:
	uae - use CPU core internal disassembler
	      (better instruction support)
	ext - use external disassembler
	      (nicer output)
	<bitmask> - disassembly output option flags
Flag values:
	0x01: ext: no space after comma in the operands list
	0x02: opcodes in lower case
	0x04: register names in lower case
	0x08: ext: stack pointer as 'SP', not 'A7'
	0x10: do not show 16-bit words at this address
	0x20: uae: show EA + CC values after instruction
	0x40: uae: hex numbers in lower case
Current settings are:
	--disasm uae --disasm 0xf

But when hatari started it reported that the flags were changed to 0x66 as I wanted. Not sure what it going on with it.

Code: Select all

Selected UAE CPU core internal disassembler.
Disassembly output flags are 0x7.
Changed CPU disassembly output flags from 0xf to 0x66.
INFO : Hatari v2.5.0-devel (Dec 19 2022), compiled on:  Dec 19 2022, 09:14:59

If I enter "setopt --disasm 0x66" from within the debugger, then it works so I think it might be using the value from the configuration file instead of the command line option overriding it. The configuration file has this value in the debugger section.

Code: Select all

[Debugger]
nDisasmOptions = 15

**Edit* yes, if I change the value in the configuration file to 0x66 then it works right away.

**Edit 2* So, if I pass the value on the command line like this then it uses the flags from the configuration file.

Code: Select all

/usr/local/bin/hatari --disasm uae --disasm 0x66 --configfile ~/.config/hatari/hatari.cfg

But, if I pass the value on the command line like this with the flag value after the configuration file specification then it does use the flag value passed as a command line override and works as expected. Kinda strange.

Code: Select all

/usr/local/bin/hatari --disasm uae --configfile ~/.config/hatari/hatari.cfg --disasm 0x66

[npomarede]

**Edit 2* So, if I pass the value on the command line like this then it uses the flags from the configuration file.

Code: Select all

/usr/local/bin/hatari --disasm uae --disasm 0x66 --configfile ~/.config/hatari/hatari.cfg

But, if I pass the value on the command line like this with the flag value after the configuration file specification then it does use the flag value passed as a command line override and works as expected. Kinda strange.

Code: Select all

/usr/local/bin/hatari --disasm uae --configfile ~/.config/hatari/hatari.cfg --disasm 0x66

Hi

it's the expected behaviour when parsing Hatari's options : options are evaluated from left to right, each new option can override some previous values on the command line.

Nicolas

[TheNameOfTheGame]

Another question about the formatting. If I set the disassembly flag:

Code: Select all

> setopt --disasm help
	0x20: uae: show EA + CC values after instruction

I can get output such as:

Code: Select all

00015632 422d 0001                clr.b (a5,$0001) == $00018c97 [00]

Which is helpful when trying to understand potential data structures or variables when reverse engineering code since it outputs the address referenced by 1(a5) when tracing. But in the following case:

Code: Select all

000161e2 1280                     move.b d0,(a1)

I don't get the address resolved for the output i.e. it doesn't output what address (a1) references.

Why does the debugger resolve the first case but not the second and is there something I can do to get the second case to display the address in the listing?

[TheNameOfTheGame]

Another question about the formatting. If I set the disassembly flag:

Code: Select all

> setopt --disasm help
	0x20: uae: show EA + CC values after instruction

I can get output such as:

Code: Select all

00015632 422d 0001                clr.b (a5,$0001) == $00018c97 [00]

Which is helpful when trying to understand potential data structures or variables when reverse engineering code since it outputs the address referenced by 1(a5) when tracing. But in the following case:

Code: Select all

000161e2 1280                     move.b d0,(a1)

I don't get the address resolved for the output i.e. it doesn't output what address (a1) references.

Why does the debugger resolve the first case but not the second and is there something I can do to get the second case to display the address in the listing?

Bump to see if I get an answer for the above question .


Also, have another question. When tracing a program I get output like this:

Code: Select all

cpu video_cyc=    72  72@  0 1057475820 : 00011634 67f8                     beq.b #$f8 == $0001162e (T)
cpu video_cyc=   136 136@  0 1057475884 : 0001552e 2f0d                     move.l a5,-(a7) [691f0003]
cpu video_cyc=   152 152@  0 1057475900 : 00015530 52b9 0000 54dc           addq.l #$01,$000054dc [00000001]
cpu video_cyc=   180 180@  0 1057475928 : 00015536 2a79 0000 5904           movea.l $00005904 [000182b4],a5
cpu video_cyc=   200 200@  0 1057475948 : 0001553c 532d 087b                subq.b #$01,(a5,$087b) == $00018b2f [1e]
cpu video_cyc=   216 216@  0 1057475964 : 00015540 6634                     bne.b #$34 == $00015576 (T)
cpu video_cyc=   228 228@  0 1057475976 : 00015576 5238 60bc                addq.b #$01,$000060bc.w [01]
cpu video_cyc=   244 244@  0 1057475992 : 0001557a 4e40                     trap #$00
cpu video_cyc=   280 280@  0 1057476028 : 00015510 4e73                     rte  == $0001557c

Is there a flag or switch to turn off the output of the video_cyc= field? It superfulous to my use and clutters up the output results, especially in a terminal where it causes word wrap.

[Eero Tamminen]

I don't get the address resolved for the output i.e. it doesn't output what address (a1) references.

Why does the debugger resolve the first case but not the second and is there something I can do to get the second case to display the address in the listing?

That comes from the WinUAE CPU core (disassembler) maintained by Toni, not from one maintained by Hatari devs. While Toni reads Hatari mailing list, he does not read Atari forum.

I.e. you should ask that on Hatari mailing list (or WinUAE forum / list).

Is there a flag or switch to turn off the output of the video_cyc= field? It superfulous to my use and clutters up the output results, especially in a terminal where it causes word wrap.

I guess Nicolas uses it when coding or debugging cycle-exact demo effects, but I've never needed it myself either.

I posted patch to put it behind its own trace flag to hatari-devel list. If there are no objections (within a week or two), I'll commit it.

If you're not on the list but are interested to apply the patch yourself before that, you should be able to pick it from the mailing list archive in few days.

(Mail archives are not real-time, TuxFamily updates them at some longer interval.)

[TheNameOfTheGame]

Sounds good, thanks for the help.

[TheNameOfTheGame]

Wow, I see the change is pushed already. Thanks, the output looks much better now on the trace.