I have a cross toolchain I configured with "--with-arch=armv7-a --with-cpu=cortex-a9 --with-tune=cortex-a9" and I want the linker to emit armv4t compatible thumb interworking, but I can't seem to get it to.
I noticed that if I create a armv4t toolchain with "--with-arch=armv4t --with-cpu=arm7tdmi --with-tune=arm7tdmi" and then I pass "--use-blx" to the linker it will emit armv7 thumb interworking. There doesn't seem to be any inverse "--no-use-blx" type switch though. Is this a bug/limitation of the linker or am I misunderstanding something?
-Allen
nvpublic
On 12/04/12 20:10, Allen Martin wrote:
I have a cross toolchain I configured with "--with-arch=armv7-a --with-cpu=cortex-a9 --with-tune=cortex-a9" and I want the linker to emit armv4t compatible thumb interworking, but I can't seem to get it to.
I noticed that if I create a armv4t toolchain with "--with-arch=armv4t --with-cpu=arm7tdmi --with-tune=arm7tdmi" and then I pass "--use-blx" to the linker it will emit armv7 thumb interworking. There doesn't seem to be any inverse "--no-use-blx" type switch though. Is this a bug/limitation of the linker or am I misunderstanding something?
it's all in the friendly manual :-)
The option you need is --fix-v4bx.
BTW, taking a v7a toolchain and trying to use it to build v4 binaries is likely to be prolematic. For it to work you'll need to ensure that *all* your libraries are built to support back-conversion to v4, including those that are normally built as part of the toolchain (libgcc, etc).
R.
-- Richard Earnshaw Email: Richard.Earnshaw@arm.com Engineering Manager Phone: +44 1223 400569 (Direct + VoiceMail) OpenSource Tools Switchboard: +44 1223 400400 ARM Ltd Fax: +44 1223 400410 110 Fulbourn Rd Web: http://www.arm.com/ Cambridge, UK. CB1 9NJ
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On 13 April 2012 11:47, Richard Earnshaw Richard.Earnshaw@arm.com wrote:
On 12/04/12 20:10, Allen Martin wrote:
I have a cross toolchain I configured with "--with-arch=armv7-a --with-cpu=cortex-a9 --with-tune=cortex-a9" and I want the linker to emit armv4t compatible thumb interworking, but I can't seem to get it to.
I noticed that if I create a armv4t toolchain with "--with-arch=armv4t --with-cpu=arm7tdmi --with-tune=arm7tdmi" and then I pass "--use-blx" to the linker it will emit armv7 thumb interworking. There doesn't seem to be any inverse "--no-use-blx" type switch though. Is this a bug/limitation of the linker or am I misunderstanding something?
it's all in the friendly manual :-)
The option you need is --fix-v4bx.
That option is for supporting pre-thumb cores, which is not necessary here.
BTW, taking a v7a toolchain and trying to use it to build v4 binaries is likely to be problematic. For it to work you'll need to ensure that *all* your libraries are built to support back-conversion to v4, including those that are normally built as part of the toolchain (libgcc, etc).
This is in the context of building a u-boot SPL for Tegra2/3. This is completely self-contained, not even relying on the compiler's libgcc.
On 13/04/12 11:58, Mans Rullgard wrote:
On 13 April 2012 11:47, Richard Earnshaw Richard.Earnshaw@arm.com wrote:
On 12/04/12 20:10, Allen Martin wrote:
I have a cross toolchain I configured with "--with-arch=armv7-a --with-cpu=cortex-a9 --with-tune=cortex-a9" and I want the linker to emit armv4t compatible thumb interworking, but I can't seem to get it to.
I noticed that if I create a armv4t toolchain with "--with-arch=armv4t --with-cpu=arm7tdmi --with-tune=arm7tdmi" and then I pass "--use-blx" to the linker it will emit armv7 thumb interworking. There doesn't seem to be any inverse "--no-use-blx" type switch though. Is this a bug/limitation of the linker or am I misunderstanding something?
it's all in the friendly manual :-)
The option you need is --fix-v4bx.
That option is for supporting pre-thumb cores, which is not necessary here.
Oops, misread the question. Sorry.
To get v4t style interworking you need to ensure all your objects are built for v4t. The use of blx should only occur if the linker detects an object file in the input list that already contains support for blx (for example, because it was compiled with v5 or later).
R.
-- Richard Earnshaw Email: Richard.Earnshaw@arm.com Engineering Manager Phone: +44 1223 400569 (Direct + VoiceMail) OpenSource Tools Switchboard: +44 1223 400400 ARM Ltd Fax: +44 1223 400410 110 Fulbourn Rd Web: http://www.arm.com/ Cambridge, UK. CB1 9NJ
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
To get v4t style interworking you need to ensure all your objects are built for v4t. The use of blx should only occur if the linker detects an object file in the input list that already contains support for blx (for example, because it was compiled with v5 or later).
I'm compiling all objects with "-mcpu=arm7tdmi -march=armv4t -mthumb-interwork" and a linker configured with "--with-arch=armv7-a --with-cpu=cortex-a9 --with-tune=cortex-a9" will always emit armv5 style interworking. If I use a linker configured with "--with-arch=armv4t --with-cpu=arm7tdmi --with-tune=arm7tdmi" then I get armv4t style interworking.
----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------
On 13/04/12 12:05, Richard Earnshaw wrote:
On 13/04/12 11:58, Mans Rullgard wrote:
On 13 April 2012 11:47, Richard Earnshaw Richard.Earnshaw@arm.com wrote:
On 12/04/12 20:10, Allen Martin wrote:
I have a cross toolchain I configured with "--with-arch=armv7-a --with-cpu=cortex-a9 --with-tune=cortex-a9" and I want the linker to emit armv4t compatible thumb interworking, but I can't seem to get it to.
I noticed that if I create a armv4t toolchain with "--with-arch=armv4t --with-cpu=arm7tdmi --with-tune=arm7tdmi" and then I pass "--use-blx" to the linker it will emit armv7 thumb interworking. There doesn't seem to be any inverse "--no-use-blx" type switch though. Is this a bug/limitation of the linker or am I misunderstanding something?
it's all in the friendly manual :-)
The option you need is --fix-v4bx.
That option is for supporting pre-thumb cores, which is not necessary here.
Oops, misread the question. Sorry.
To get v4t style interworking you need to ensure all your objects are built for v4t. The use of blx should only occur if the linker detects an object file in the input list that already contains support for blx (for example, because it was compiled with v5 or later).
R.
I've just built an assembler/linker with the options you mention.
Compiling the following testcase:
.text .arm .cpu arm7tdmi .global _start .type _start, %function _start: bl bar bx lr .thumb .global bar .type bar, %function bar: bx lr
Results in:
.../as /tmp/asm.s -o /tmp/asm.o .../ld -o /tmp/asm /tmp/asm.o
.../objdump -d /tmp/asm
/tmp/asm: file format elf32-littlearm
Disassembly of section .text:
00008000 <_start>: 8000: eb000002 bl 8010 <__bar_from_arm> 8004: e12fff1e bx lr
00008008 <bar>: 8008: 4770 bx lr 800a: 46c0 nop ; (mov r8, r8) 800c: 0000 movs r0, r0 ...
00008010 <__bar_from_arm>: 8010: e59fc000 ldr ip, [pc] ; 8018 <__bar_from_arm+0x8> 8014: e12fff1c bx ip 8018: 00008009 .word 0x00008009 801c: 00000000 .word 0x00000000
Change the .cpu directive to .cpu cortex-a9 and you get
objdump -d /tmp/asm
/tmp/asm: file format elf32-littlearm
Disassembly of section .text:
00008000 <_start>: 8000: fa000000 blx 8008 <bar> 8004: e12fff1e bx lr
00008008 <bar>: 8008: 4770 bx lr 800a: bf00 nop
So exactly how are you calling the linker?
I've just built an assembler/linker with the options you mention.
Compiling the following testcase:
.text .arm .cpu arm7tdmi .global _start .type _start, %function _start: bl bar bx lr .thumb .global bar .type bar, %function bar: bx lr
Results in:
.../as /tmp/asm.s -o /tmp/asm.o .../ld -o /tmp/asm /tmp/asm.o
.../objdump -d /tmp/asm
/tmp/asm: file format elf32-littlearm
Disassembly of section .text:
00008000 <_start>: 8000: eb000002 bl 8010 <__bar_from_arm> 8004: e12fff1e bx lr
00008008 <bar>: 8008: 4770 bx lr 800a: 46c0 nop ; (mov r8, r8) 800c: 0000 movs r0, r0 ...
00008010 <__bar_from_arm>: 8010: e59fc000 ldr ip, [pc] ; 8018 <__bar_from_arm+0x8> 8014: e12fff1c bx ip 8018: 00008009 .word 0x00008009 801c: 00000000 .word 0x00000000
Change the .cpu directive to .cpu cortex-a9 and you get
objdump -d /tmp/asm
/tmp/asm: file format elf32-littlearm
Disassembly of section .text:
00008000 <_start>: 8000: fa000000 blx 8008 <bar> 8004: e12fff1e bx lr
00008008 <bar>: 8008: 4770 bx lr 800a: bf00 nop
So exactly how are you calling the linker?
The original example I was trying to debug was u-boot, which is a complicated example because it uses a custom linker script and it's own libgcc, but using your "readelf -A" hint I was able to track down that some of my objects were compiled armv5.
I also created a simple 2 function test in C
$ cat main.c void main(void); int arm_incr(int x); void main(void) { int x = arm_incr(2); }
$ cat arm.c int arm_incr(int x) { return x + 1; }
$ arm-cortex_a9-linux-gnueabi-gcc -mcpu=arm7tdmi -march=armv4t -mthumb-interwork -mthumb -c -o main.o main.c $ arm-cortex_a9-linux-gnueabi-gcc -mcpu=arm7tdmi -march=armv4t -mthumb-interwork -marm -o arm.o -c arm.c $ arm-cortex_a9-linux-gnueabi-gcc -mcpu=arm7tdmi -march=armv4t -mthumb-interwork -o thumbtest main.o arm.o
But because I wasn't supplying arm armv4t sysroot it pulled in armv7 crt*.o files so it showed the same problem as my u-boot.
I think this is resolved now, I modified my simple test to use an armv4t sysroot and libgcc and verified it does the correct thing, so I'm confident I can make my u-boot work too. Thanks for your assistance.
-Allen
nvpublic
On Fri, Apr 13, 2012 at 11:58:02AM +0100, Mans Rullgard wrote:
On 13 April 2012 11:47, Richard Earnshaw Richard.Earnshaw@arm.com wrote:
BTW, taking a v7a toolchain and trying to use it to build v4 binaries is likely to be problematic. For it to work you'll need to ensure that *all* your libraries are built to support back-conversion to v4, including those that are normally built as part of the toolchain (libgcc, etc).
Why can't a toolchain (especially a prebuilt binary one) support multilib and provide all the variants of libgcc and friends for armv4/5/6/7?
This is in the context of building a u-boot SPL for Tegra2/3. This is completely self-contained, not even relying on the compiler's libgcc.
linaro-toolchain@lists.linaro.org
-
Allen Martin -
Denys Dmytriyenko -
Mans Rullgard -
Richard Earnshaw -
Richard Earnshaw