[Solved]A Problem in Assembling ARM source file

Questions
1

Hello,everyone!As you can see, I’m a newcomer to this community :slight_smile:

Recently I have encountered a problem while assembling source file using the tool devkitARM, which is all of the branch codes are compiled abnormally. The codes such as “bl 0x08XXXXXX” are compiled to “bl itself”,which is 0xFFFE7FFF. Of course,it doesn’t work except I modify all of the errors in a hex editor manually. I’d appreciate it if anyone here can tell me how to solve the problem. I know the question sounds stupid but I am really new to this tool.(In fact, I did the asm hack using a debugger and a hex editor before.) And because I am not a native English speaker so if I haven’t account the question clearly, let me konw.

Here is my assemble.bat:

@echo off

SET startDir=D:\devkitPro\devkitARM\bin\

@rem Assemble into an elf
SET as="%startDir%arm-none-eabi-as"
%as% -g -mcpu=arm7tdmi -mthumb-interwork %1 -o “%~n1.elf”

@rem Print symbol table
SET readelf="%startDir%arm-none-eabi-readelf"
%readelf% -s “%~n1.elf” > “%~n1.symbols.log”

@rem Extract raw assembly binary (text section) from elf
SET objcopy="%startDir%arm-none-eabi-objcopy"
%objcopy% -S “%~n1.elf” -O binary “%~n1.dmp”

echo y | del “%~n1.elf”
pause

And here is the problem:

So I need to modify them manually:

2

You’ve shown us everything except the most obvious source of the problem, i.e. the actual assembly listing you’re starting with.

3

for whatever reason gas/gcc no longer accepts bl to an absolute address (actually, i’m surprised that it didn’t give you an error - at least as far as gas is concerned, 0x8whatever is way out of bl range) and instead treats it as a label or something of the sort

you can get around this by making a label that’s .org’d to the relevant place and bl’ing to that, or by using a macro

4

@CT075
In fact, I only know where in the rom I should branch and have no idea of the actual codes there.

5

Did you mean the .symbols.log file generated?

6

No, I mean the actual asm code that you wrote.

If you are trying to branch to existing code, BL is probably not what you want - it can only work if you put your code inside the first 4MB of the ROM, and you won’t realistically find space there unless you get rid of existing code. Anyway, you should try to write your code so that it doesn’t matter where you put it. That means that ordinary BL will not work, because it’s relative and you want an absolute address. You need to set up a BX instead. Please see these two threads.

7

@zahlman

The actual asm code is in the “FEditor Adv\asm\FE7\Spell Anim System” called CSA System.txt. In the reality I need to modify the system because of some reason, so I need to modify the source and re-assemble it. But I encountered that problem while trying to assemble the original unmodified src>_<(But why Xeld hadn’t encountered the problem and compiled it correctly?) I edited the code directly in the hex editor and ran VBA to test it, the branches worked well, but there are too many branches in the system for me to calculate each offset and modify them manually. I have encountered the same problem before while compiling my modified hack based on Nintenlord’s hack and modified the branch mistakes in a debugger one by one and the hack worked pretty well, so I think my way of compilation may have some errors.
I will research your treatise and try to use bx to replace the bl code.Thanx~

8

Here’s how I did bl in modular battle. This is the way devkitArm want it, I think.

.org 0x285A8
Hit_Determination:


.org 0x29264

@. . . CODE . . .

ldrh    r0,[r6,#0xA]
mov     r1,#0x1
bl      Hit_Determination
9

@Crazycolorz5

I did in this way but it informed " Error: attempt to move .org backwards". What does that mean?

I have uploaded my source file:

There may be some mistakes in the src because I can’t test it before I solve the problem and I only want to compile it successfully now>_<

In fact, I replace the “bl 0x08XXXXXX - CSAPS_CORRECT” in Xeld’s src with the following:

.set BLX,0x08XXXXXX - CSAPS_CORRECT

@ the place where “bl 0x08XXXXXX - CSAPS_CORRECT” was
bl BRANCH_DESTINATION_X

.org BLX
BRANCH_DESTINATION_X:

That cannot be compiled.

10

You need the .org’s in order. So cut the code you have at the bottom and put it at the top.

BUT, if you’re using some kind of patcher format, which you seem to be using? Then you use that spec and not the arm bl.

11

Patcher format?Considering my poor English and I don’t know if I understand it correctly.The FEditor Adv uses auto-patch so the changes to rom are directly written in the java source file.Is that connected with the compilation?

12

I mean your using of this.

Try putting the second .org at the top of the file.

13

I have changed the position but it seems no help.

14

What I mean is, I don’t use the .set.

15

Could you please post your entire source file?

16

I have uploaded it here.

17

Hmm… sorry, I don’t know how to work with .set and Hex’s patcher format (I don’t have any experience with it). @CT075?

18

What confused me is why Xeld and Nintenlord can compile their src correctly but it(even unmodified one) didn’t work for me.The souce is absolutely the same.

The unmodified src file here:
CSA System.txt

Xeld’s compiled dump:

CSA System.dump.bak

My compiled dump:

CSA System.dump

the differences between the two dump files above(compared by the command “fc /b”)

00000052: 88 FF
00000054: E9 FE
0000005A: 84 FF
0000005C: A1 FE
0000005D: FC FF
0000005E: 84 FF
00000060: AB FE
00000061: FC FF
00000066: 38 FF
00000068: ED FE
00000069: FE FF
00000074: 89 FF
00000076: 9E FE
00000077: F8 FF
0000007C: 88 FF
0000007E: DE FE
00000180: 84 FF
00000182: CC FE
00000183: F9 FF
000001AC: 88 FF
000001AE: D4 FE
000001F6: 84 FF
000001F8: 7B FE
000001F9: FC FF
000001FC: 84 FF
000001FE: 4E FE
000001FF: FD FF
0000020C: 9C FF
0000020E: 5A FE
0000020F: FA FF
00000248: 82 FF
0000024B: FD FF
00000258: 9C FF
0000025A: 9C FE
0000025B: FC FF
000003E2: 84 FF
000003E4: E3 FE
000003E5: FA FF
000003E6: 84 FF
000003E8: C5 FE
000003E9: F8 FF
000003EC: 38 FF
000003EE: 30 FE
000003EF: FE FF

All of the differences are generated by bl code.

19

hextator is using an old build of devkitARM, the most important part of which is that the version of gas/gcc involved allows you to bl to an absolute address, which i already mentioned

this line, for example:

bl				0x08054678 - CSAPS_CORRECT

this works, but only in devkitARM16 or below. beyond that for whatever reason, gas will not let you bl to a number, only to a label. I can’t remember offhand what the solution to that was (there definitely is one; i’ve used it myself), play around with the math a bit.

20

@CT075

Thanks for your kind explanation.I have solved the problem by install a old version of devkitARM.

The oldest version of devkitARM I can find is devkitARM_r36 released on 2011-10-15 here:

devkitARM previous