Android CLEO issue.

[x87]

Finally, there is an Android CLEO issue.
I am trying to implement static injection of ARM assembly code in Android CLEO. I succeeded, but there is an architectural problem. I very much hope that the SB tool can add a function to solve the problem:

{$CLEO .csa}
0000:
jump @1

:ASM
hex
 AEF12D00 //SUB R0, LR, #0x2D
 F746     //MOV PC, LR
end

:1
wait 0
0DD0: 39@ = get_label_addr @ASM
0DD8: 1@ = read_mem_addr 39@ size 4 add_ib 0
39@ += 4
0DD8: 2@ = read_mem_addr 39@ size 2 add_ib 0
39@ -= 4
0DD9: write_mem_addr 39@ value 1@ size 4 add_ib 0 protect 1
39@ += 4
0DD9: write_mem_addr 39@ value 2@ size 2 add_ib 0 protect 1
39@ -= 4
//It must be read first, and then written as protect 1. 
//Because what Android CLEO.so is loaded is not the game memory space,
// but the static memory space allocated by the Android system, 
//which cannot be accessed directly. 
//This may be because of the rigor of the Android system

39@ += 1 
//Because it is a thumb instruction, the return address is automatically +1
//BLX will automatically recognize the switching instruction set
//The lowest bit of BLX address is 1 for Thumb, and 0 for Arm
//Android GTA uses ARMV7 and Thumb mixed instructions
0DD2: context_call_func 39@
0DD4: 0@ = context_get_reg 0 //0@= asm call addr
0DD8: 10@ = read_mem_addr 0@ size 1 add_ib 0
01E5: show_text_1number_highpriority GXT 'NUMBER' number 10@ time 10000 flag 1
end_thread

The above code gets the memory address of the function asm_call in CLEO.SO in the Android cleo library, and reads its first byte for display.
Just test the code, in fact, 0DD2 CALL calls itself to access its own address. This is also the OP implementation of ODD2.

But the problem is not here. The ASM assembly code at the beginning must be placed at the beginning of CLEO. If placed at the end, the game will crash and report an error.
After I spent time researching, the error code is as follows:

Exception signal: 7 (SIGBUS)
Exception code: Ox1 (BUS_ ADRALN)

When accessing memory, the data is not aligned
The new code is placed at the end:

0DD0: 39@ = get_label_addr @ASM
0DD8: 1@ = read_mem_addr 39@ size 4 add_ib 0
39@ += 4
0DD8: 2@ = read_mem_addr 39@ size 2 add_ib 0
39@ -= 4
0DD9: write_mem_addr 39@ value 1@ size 4 add_ib 0 protect 1
39@ += 4
0DD9: write_mem_addr 39@ value 2@ size 2 add_ib 0 protect 1
39@ -= 4
39@ += 1
0DD2: context_call_func 39@
0DD4: 0@ = context_get_reg 0
0DD8: 10@ = read_mem_addr 0@ size 1 add_ib 0
01E5: show_text_1number_highpriority GXT 'NUMBER' number 10@ time 10000 flag 1
end_thread

hex
00
end

If you do not add hex 00 end here to fill a byte to align the data, the game will crash. I noticed that this problem only occurs in Android, which is also the particularity of the architecture. It seems that the CLEO code will affect the alignment in memory?
It would be better if SB can automatically add extra bytes when compiling Android CLEO, but this is only suitable for advanced Android CLEO development

:ASM
hex
AEF12D00 //SUB R0, LR, #0x2D
F746     //MOV PC, LR
end

Originally posted by @XMDS in #33 (comment)

[XMDS]

Regarding the Android cleo data alignment issue. On the forum topic fastman92 proposed a solution of sannybuilder. But even so, as wesser said, unless CLEO is aligned on a 4-byte boundary at runtime
@x87 You can take a look at the last few replies of this topic :
https://gtaforums.com/topic/961013-solutions-to-some-problems-of-gta-android-cleo/

[x87]

@XMDS from what I see if the runtime does not guarantee the alignment of the script start address there is nothing I can do in compile time. Even if I perfectly align byte code instructions they still could be shifted 1-, 2- or 3 bytes when the script is loaded. It should be solved on a run-time level (CLEO Android in this case) but I doubt it ever happens.

[x87]

I think memmove is a good workaround.