The label cannot be decompiled correctly 2

[XMDS]

@x87 In some cases this problem still exists. In fact, I don't have an example, but I decompile the cleo that I wrote before and still have this problem. I noticed that when a cleo has a lot of hex (string，assembly) code, some OP tags are still not properly decompiled:

0AC6: 15@ = label -2315 pointer
0AB1: cleo_call -2367 3 3@ 4@ 5@


Android’s 0DD2 is worse than PC’s two：

0DD0: 33@ = get_label_addr -22 // android 
0DD1: 33@ = get_func_addr_by_cstr_name 33@ // android 
004E: terminate_this_script 

:NONAME_22
hex
 5F 5A 4E 36 43 50 6F 6F 6C 73 31 34 6D 73 5F 70
 4F 62 6A 65 63 74 50 6F 6F 6C 45 00
end

And there is no problem in the previous version

[x87]

@XMDS can you share this file?

[x87]

#81 #99

[XMDS]

@x87 Simple sample code：

{$CLEO .cs}
0000:
0AC6: 0@ = label @Kernel32_dll pointer
0AC6: 0@ = label @GetModuleHandleExA pointer
0AC6: 0@ = label @GetVersionFunc pointer
0AC6: 0@ = label @GetFileAttributesA pointer
0AC6: 0@ = label @OPPlusFilePath pointer
0AC6: 0@ = label @ASM_call_GetModuleHandleExA pointer


:Kernel32_dll
hex
 "Kernel32.dll" 00
end

:GetModuleHandleExA
hex
 "GetModuleHandleExA" 00
end

:GetVersionFunc
hex
 "?CLEO_GetVersion@@YAIXZ" 00
end

:GetFileAttributesA
hex
 "GetFileAttributesA" 00
end

:OPPlusFilePath
hex
 "\\CLEO\\SCR\\OP+" 00
end

:ASM_call_GetModuleHandleExA
hex
{0000} 55              //push    ebp
{0001} 8BEC            //mov     ebp, esp
{0003} 83EC 04         //sub     esp, 4
{0006} 8D45FC          //lea     eax, [ebp-4]  
{0009} 50              //push    eax
{000A} 8B45 04         //mov     eax, [ebp+4] 
{000D} 50              //push    eax
{000E} 6A 06           //push    6
{0010} E8 00000000     //call    GetModuleHandleExA
{0015} 8B45FC          //mov     eax, [ebp-4]
{0018} 83C4 04         //add     esp, 4
{001B} 5D              //pop     ebp
{001C} C3              //ret
end

Decompile:

{$CLEO .cs}

0000: NOP 
0AC6: 0@ = label -62 pointer 
0AC6: 0@ = label -75 pointer 
0AC6: 0@ = label -94 pointer 
0AC6: 0@ = label -118 pointer 
0AC6: 0@ = label -137 pointer 
0AC6: 0@ = label -151 pointer 

:NONAME_62
hex
 4B 65 72 6E 65 6C 33 32 2E 64 6C 6C 00
end

:NONAME_75
hex
 47 65 74 4D 6F 64 75 6C 65 48 61 6E 64 6C 65 45
 78 41 00
end

:NONAME_94
hex
 3F 43 4C 45 4F 5F 47 65 74 56 65 72 73 69 6F 6E
 40 40 59 41 49 58 5A 00
end

:NONAME_118
hex
 47 65 74 46 69 6C 65 41 74 74 72 69 62 75 74 65
 73 41 00
end

:NONAME_137
hex
 5C 43 4C 45 4F 5C 53 43 52 5C 4F 50 2B 00
end

:NONAME_151
hex
 55 8B EC 83 EC 04 8D 45 FC 50 8B 45 04 50 6A 06
 E8 00 00 00 00 8B 45 FC 83 C4 04 5D C3
end

CLEO_CALL is the same, when there is hex, so is 0DD0 of Android

[x87]

@XMDS I found an interesting quirk testing this script. If I compile the script without Extra info and then disassemble it with IGNORE_UNKNOWN I get different result:

// This file was decompiled using SASCM.ini published on 2020-11-11
{$CLEO .cs}
{$USE CLEO+}

0000: NOP 
0AC6: 0@ = label @NONAME_62 pointer 
0AC6: 0@ = label -75 pointer 
0AC6: 0@ = label @NONAME_94 pointer 
0AC6: 0@ = label -118 pointer 
0AC6: 0@ = label -137 pointer 
0AC6: 0@ = label -151 pointer 

:NONAME_62
hex
 4B 65 72 6E 65 6C 33 32 2E 64 6C 6C 00 47 65 74
 4D 6F 64 75 6C 65 48 61 6E 64 6C 65 45 78 41 00
end

:NONAME_94
hex
 3F 43 4C 45 4F 5F 47 65 74 56 65 72 73 69 6F 6E
 40 40 59 41 49 58 5A 00
end

:NONAME_118
hex
 47 65 74 46 69 6C 65 41 74 74 72 69 62 75 74 65
 73 41 00 5C 43 4C 45 4F 5C 53 43 52 5C 4F 50 2B
 00 55 8B EC 83 EC 04 8D 45 FC 50 8B 45 04 50 6A
 06 E8 00 00 00 00 8B 45 FC 83 C4 04 5D C3

It properly restored 2 of 3 labels.

If I compile the script with Extra info, then open it and decline a request to use the original source code I get the same result as you. I will need to look into why the behavior is different in these cases.

[XMDS]

@x87 As you said. In fact, in one of my cleos, when I decompile, some labels are displayed normally, but some labels are not displayed normally. I have just gone through a lot of testing, I don’t know why this is so, so I didn’t have too many clear examples to provide, especially 0AB1 cleo_call. I still don’t have a simple example to provide. It is only in my old VC CLEO appear. In addition, the same is true for Android 0DD0, it is sometimes normal, but some scripts are not displayed.
In addition, other OPs such as jump and gosub are normal. I did not find any problems with them.

[x87]

So two things here. First, when the script is compiled with Extra info there is an information on hex..end locations so the disassembler is able to properly restore the labels. It was just that those hex location were not accounted as valid label offsets, so you see the numbers in 0AC6. This has been fixed, will be delivered in the next version.

But for IGNORE_UNKNOWN (when the script does not have Extra info) it's not fixable at this point. Due to implementation details the disassembler skips some potential targettable offsets during scanning (it steps in 2 bytes when ignoring unknown data). So you see some labels present and some not. This can be improved eventually with #33 specifically and reducing stepping to 1 byte, but it requires major refactoring. I will create a separate issue for this.

[x87]

there is an issue with how disassembler treats absolute offsets in missions/cleo scripts.

given a script:

{$CLEO .cs}
gosub 100 

after disassembling it becomes:

{$CLEO .cs}
gosub -100