TMS470 assembler complains about "out of range" for BLX

42Bastian

Hi, I need a hint. I am using blx in a CR4 project and there asm470 complains:


"sciopta.asm", ERROR!   at line 3186: [E0200] Offset out of range, must be  [-4194304,4194303]

                blx     cpu_unlock_r12

My problem, I am compiling with "-c", so the assembler cannot know anything about the distances.
_And_, the distance in this file would be 20k at max.
Any hint ? TIA

over 13 years ago

0 AartiG over 13 years ago

TI__Guru**** 173310 points

Could you please attach the source file that triggers this error, along with specific build options? Also which version of the tools are you using?

0 42Bastian over 13 years ago in reply to AartiG

Expert 1430 points

Hi
here is the code


   .text

   .thumb

   blx   hello

   nop



   .sect ".hello"

   .align 4

hello:   nop

It is valid for Thumb as well as for Thumb-2, but compiles only for v5e,v6,7m3 and 7m4 but not 7A8 nor 7R4.
ok: cl470 -mv 6 --abi=eabi t.asm
ko: cl470 -mv 7r4 --abi=eabi t.asm

"t.asm", ERROR!   at line 3: [E0200] Offset out of range, must be

                                     [-4194304,4194303]

Compiler: 4.9.4/4.9.6

If the destination of blx is not in another section, the code compiles fine.
But this is no real option, as it would enlarge our RTOS binary significantly as it would disable dead code removing.
So I hope to see a fix soon.

0 JohnN over 13 years ago in reply to 42Bastian

TI__Prodigy 525 points

Hi Bastion,

I cut/pasted your example:

   .text
   .thumb
   blx hello
   nop

.sect ".hello"
.align 4
hello: nop

into a file and was not able to reproduce the error using 4.9.4, or 4.9.6 versions of the tools:

==> cl470 --tool_version

TMS470 C/C++ Compiler v4.9.4
Build Number 1MCTM-JIK27-UARAR-SAW-ZAZE_U_Z9_U

==> cl470 -mv 7r4 --abi=eabi t.asm

==> cl470 --tool_version

TMS470 C/C++ Compiler v4.9.6
Build Number 1MFQK-JIK27-UARAR-SAW-ZAZE_U_Z9_W

==> cl470 -mv 7r4 --abi=eabi t.asm

Ran disassembler on unlinked .obj file to verify assembly:

dis470 xx.obj
Disassembly of xx.obj:

TEXT Section .text, 0x6 bytes at 0x0
000000:               .thumb
000000: F7FFEFFE         BLX             hello [0x0]
000004: BF00             NOP

TEXT Section .hello, 0x2 bytes at 0x0
000000:               .thumb
000000:              .hello:
000000:              hello:
000000: BF00             NOP

Regards,

John N

0 42Bastian over 13 years ago in reply to JohnN

Expert 1430 points

Hi John, bizarre. Here is what I did:

/tmp_dev/arm >cat t.asm
.text
.thumb
blx hello
nop

.sect ".hello"
.align 4
hello: nop
/tmp_dev/arm >cl470 -mv 7r4 --abi=eabi t.asm
"t.asm", ERROR! at line 3: [E0200] Offset out of range, must be
[-4194304,4194303]
blx hello

1 Assembly Error, No Assembly Warnings

Errors in Source - Assembler Aborted

>> Compilation failure
/tmp_dev/arm >cl470 --tool_version
TMS470 C/C++ Compiler v4.9.6
Build Number 1MFQK-KDADEMDK-RTARQ-WAR-ZAZE_U_Z9_W

I also found out that the BLX offset are not correctly linked. But I am just trying to make an example.

0 42Bastian over 13 years ago in reply to JohnN

Expert 1430 points

Hi, ok, I have attached an example showing BLX is buggy.
I replaces BLX by BL even though it is a jump from Thumb to ARM mode and calculates the offset wrong.
My command lines:
cl470 -mv7r4 -al -mt t.asm --abi=eabi
cl470 -mv7r4 -mt --abi=eabi -z -m x.map simple.cmd t.obj
simple.cmd
--entry_point=main
MEMORY
{
rom : ORIGIN = 0 LENGTH = 1024
}
SECTIONS
{
.text load = rom, run = rom
}

0 JohnN over 13 years ago in reply to 42Bastian

TI__Prodigy 525 points

Again I was not able to reproduce a problem using your new test case. However, I was able to reproduce the original assembler 'out-of-range' error and reproduce the linked example from your previous post using the 4.4.x tool chain. Can you verify that you are using 4.9.6 asm470? Invoking cl470 --tool_version should report version numbers for the entire toolchain.

Regards,

John N

0 42Bastian over 13 years ago in reply to JohnN

Expert 1430 points

Hi, I checked, and I have only 4.9.1,2,4 and 6 on my PC.
In my current path is 4.9.6 and all tools show the same build:
TMS470 C/C++ Compiler v4.9.6
Build Number 1MFQK-KDADEMDK-RTARQ-WAR-ZAZE_U_Z9_W

0 JohnN over 13 years ago in reply to 42Bastian

TI__Prodigy 525 points

Bastian,

This is peculiar as I get correct results using 4.9.x tools as you can see below. I also had someone else reproduce the same results using their environment:

(4.9.6)==> cl470 --tool_version
TMS470 C/C++ Compiler v4.9.6
Build Number 1MFQK-JIK27-UARAR-SAW-ZAZE_U_Z9_W

TMS470 Assembler v4.9.6
Build Number 1MFQK-JIK27-UARAR-SAW-ZAZE_U_Z9_W

(4.9.6)==> cat t.asm
       .text
       .thumb
       .global main
main: .asmfunc
       nop
       blx      test
       nop
       bx       lr
       .endasmfunc

       .global test
       .arm
       .armfunc test
test: .asmfunc
       bx       lr
       .endasmfunc

(4.9.6)==> cat simple.cmd
--entry_point=main
MEMORY
{
rom : ORIGIN = 0 LENGTH = 1024
}
SECTIONS
{
.text load = rom, run = rom
}

(4.9.6)==> cl470 -mt -mv7r4 --abi=eabi t.asm

(4.9.6)==> cl470 -mt -mv7r4 --abi=eabi -z -m x.map simple.cmd t.obj -o t.out
<Linking>
(4.9.6)==> dis470 t.out

Disassembly of t.out:

TEXT Section .text, 0x10 bytes at 0x0 [Loaded from 0x10]
000000:              main:
000000:              __TI_static_base__:
000000:               .thumb
000000: 00BF             NOP
000002: 00F004E8         BLX             test [0xc]
000006: 00BF             NOP
000008: 7047             BX              R14
00000a: C046             MOV             R8, R8
00000c:              test:
00000c:               .arm
00000c: 1EFF2FE1         BX              R14

If I revert tools version back to 4.7.1 (or earlier), I can reproduce the incorrect result you observed:

(4.7.1)==> cl470 --tool_version

TMS470 C/C++ Compiler v4.7.1
Build Number 1KJLP-JIK27-UARAR-SAW-ZAZE_U_X_R

TMS470 Assembler v4.7.1

(4.7.1)==> cl470 -mt -mv7r4 --abi=eabi t.asm
(4.7.1)==> cl470 -mt -mv7r4 --abi=eabi -z -m x.map simple.cmd t.obj -o t.out
<Linking>
(4.7.1)==> dis470 t.out

Disassembly of t.out:

TEXT Section .text, 0x10 bytes at 0x0 [Loaded from 0x10]
000000:              __TI_static_base__:
000000:               .thumb
000000: 00BF             NOP
000002: FFF7FFFF         BL              0x00000004
000006: 00BF             NOP
000008: 7047             BX              R14
00000a: C046             MOV             R8, R8
00000c:              test:
00000c:               .arm
00000c: 1EFF2FE1         BX              R14

Can you attach the .obj and the .out file from your example build?

Regards,

John N

0 42Bastian over 13 years ago in reply to JohnN

Expert 1430 points

Hi,
now this is strange. I checked again, and no CGTs older than 4.9.1 on my computer.
I attached a .zip with t.asm,t.obj,t.out and x.map
BTW: Another bug concerning BLX :(

	.thumb
	.global	main
main:	.asmfunc
	nop
	blx	test
	blx	main
	nop
	bx	lr
	.endasmfunc

"t.asm", ERROR!   at line 7: [E0200] Destination must be on a 2 byte boundary
                blx     main

But "blx" from Thumb to Thumb is valid.
But unless you can't reproduce the error, there is little hope it'll get fixed :(
Just a side-note (to increase pressure :-) : For me it is a show-stopper porting our RTOS to CCS

BTW: Compiling with -mv5e works!

t.zip

0 JohnN over 13 years ago in reply to 42Bastian

TI__Prodigy 525 points

I have attached the 4.9.6 asm470 from our release repository. Please replace your version with this to see if you can reproduce my results. I ran your new test case and did not get the '2 byte boundary' error with 4.9.4/6, but was able to generate the error using the 4.7.1 tools.

Your symptoms indicate problems that were present in the 4.7.x tools but the object files you sent have build attributes reflecting 4.9.x tools (using 'ofd470 --obj_display=all t.obj') .

6505.4_9_6_asm.zip

Regards,

John N

0 42Bastian over 13 years ago in reply to JohnN

Expert 1430 points

Hi
so now we get closer.
I am not using the tools on Linux, but on Win7-64 (I guess me using shell confused). Maybe there is a difference in the assemblers ? Wrong sources taken for the build.
Could you retry my examples using the Windows tools ?
Anyway, I do not thing asm470 is the (only) problem, a the assembled object file shows (besides the 2byte boundary problem) the correct opcode, but the linker replaces it by a BL.

0 JohnN over 13 years ago in reply to 42Bastian

TI__Prodigy 525 points

Bastion,

There does seem to be some Linux vs Windows issue. For your original test case (the 'out of range') error I did use Windows executables but could not reproduce that error. I then switched to Linux for your other test cases (I noticed you were using shell 'cat', etc). Using linux tools I could not reproduce. I switched back to windows 4.9.6 and can now reproduce the problems for the newer test cases (I still can't reproduce the 'out of range' error). So there appears to be some platform issue. From what I know of the release build process the same source is used for both builds so I don't think it is an issue with using old sources.

As a workaround can you use 'BLX.W' instead of 'BLX' ? I tried that on your test cases and the output looks correct. I don't believe the linker is part of the problem as it uses an assembler generated relocation entry to process. I will try to build a PC version by hand (ie outside of our build process) to see if the problem corrects. If it works I will forward to you.

Regards,

John N

0 42Bastian over 13 years ago in reply to JohnN

Expert 1430 points

Hi John,
using blx.w was a good hint. Though the resulting code in t.obj is not correct:

EXT Section .text, 0x18 bytes at 0x0
000000:              main:
000000:               .thumb
000000: BF00             NOP
000002:              mainx:
000002: F7FFFFFE         BL              test [0x2]
000006: F7FFFFFB         BL              Lib$$Request$$cpplib [0x0]
00000a: BF00             NOP
00000c: 4770             BX              R14
00000e: 46C0             MOV             R8, R8
000010:              test:
000010:               .arm
000010: FAFFFFFE         BLX             mainx [0x10]
000014: E12FFF1E         BX              R14

As you see, asm470 generates "bl" instructions though the source is "blx.w". But the linker fixes the "bl" to ARM mode by BLX.
Not 100% what I need, but I could live with it for the time being.
Tried also .N, which really assembled as BLX without the 2-byte boundary error, but the Thumb to Thumb BLX gets the wrong offset (bit 0 == 0), resulting in a state change.

000002: F7FFEFFE         BLX             test [0x0]
000006: F7FFEFFB         BLX             Lib$$Request$$cpplib [0x0]

But despite this (I am not sure, if it is a wrong use of the BLX) I will use BLX.N.
Still strange that the Windows application behaves different from the Linux application.

Anyway, I am step further. Let's see what comes up next (I haven't tried to assemble the kernel for CM3 and ARM7TDMI yet :-) )
Thanks so far. BTW: It is Basti a n, nothing military ;-)

0 42Bastian over 13 years ago in reply to JohnN

Expert 1430 points

Hi John,
at first glance, our kernel runs (after fixing a bug :-)
Again thanks for the help.

0 JohnN over 13 years ago in reply to 42Bastian

TI__Prodigy 525 points

Bastian,

Sorry about the name mispelling. I built a Windows 4.9.6 by hand and still get the behavior difference from the Linux version even though the source is the same. Very weird. I am glad the workaround will allow you to continue development. I will submit this issue into the bug tracking system and forward you the ClearQuest number.

Regards,

John

0 42Bastian over 13 years ago in reply to JohnN

Expert 1430 points

Hi John

JohnN said:

Sorry about the name mispelling.

No problem, you were not the first and likely will not be the last ;-)

Code Composer Studio™︎

Code Composer Studio forum

TMS470 assembler complains about "out of range" for BLX