Spurious Labels
AlexanderAdelAU opened this issue · 5 comments
The following code is strictly speaking invalid, however the disassembler produces spurious labels which is a potential issue.
The offending label that is generated mov r4, @scan
For example, this code
04 60 01 08 00 00 2D C0 02 04 01 12 C8 04 01 1E
2D C0 00 00 02 04 00 03 C8 04 00 0E 2D C0
produces
aorg >0100
0100 0460 b @>0108
0102 0108
0104 0000 data >0000
0106 2dc0 xop r0, r7
0108 0204 li r4, >0112
010a 0112
010c c804 mov r4, @>011e
010e 011e
0110 2dc0 xop r0, r7
0112 0000 data >0000
0114 0204 li r4, >0003
0116 0003
0118 c804 mov r4, @scan
011a 000e
011c 2dc0 xop r0, r7
If I understand you correctly your issue is that the line
0118 c804 mov r4, @scan
should really be returned as
0118 c804 mov r4, @>000e
If so, than I agree with you. What happens right now is that the disassembler replaces some constants by built-in labels, such as
>8800 by vdprd
>8c02 by vdpwa
>000e by scan
...
When I get some time, I'll try to add some context information, so that scan will only be inserted when >000e is part of a branch, or vdp* is inserted when the value is part of a data argument.
I am not too familiar with Python but I probably should have scanned the code to pick this up. So yes context information would help. If you still have time :-) would you be able to fix the XOP disassembly so that the 2nd argument of the XOP instructions is not presented as a register.?
Oh, that XOP disassembly is a bug! I'll fix it in the next release, together with the symbols. Not sure when that will be released, but probably around summer.
Oh, and I forgot to say, in both cases, thanks for reporting bugs! Only reporting makes the tools better. 😃
My pleasure. I am trying to debug a linker loader at the moment and being able to disassemble is a great help.