Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Spurious Labels #20

Open
AlexanderAdelAU opened this issue Apr 17, 2020 · 5 comments
Open

Spurious Labels #20

AlexanderAdelAU opened this issue Apr 17, 2020 · 5 comments

Comments

@AlexanderAdelAU
Copy link

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
@endlos99
Copy link
Owner

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.

@AlexanderAdelAU
Copy link
Author

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.?

@endlos99
Copy link
Owner

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.

@endlos99
Copy link
Owner

Oh, and I forgot to say, in both cases, thanks for reporting bugs! Only reporting makes the tools better. 😃

@AlexanderAdelAU
Copy link
Author

My pleasure. I am trying to debug a linker loader at the moment and being able to disassemble is a great help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@endlos99 @AlexanderAdelAU