Sorry fo the delay in responding. I couldn't find the time to do the experiments in the last couple of days.
On Wednesday 16 March 2011 07:14 PM, Ulrich Weigand wrote:
Aneesh Vaneesh@ti.com wrote on 03/16/2011 10:32:50 AM:
Can you try this sequence:
arm-linux-gnueabi-gcc -march=armv7-a -mthumb -mthumb-interwork -o foo1.o foo1.c -c arm-linux-gnueabi-gcc -march=armv7-a -mthumb -mthumb-interwork -o foo2.o foo2.S -c arm-linux-gnueabi-ld -r foo1.o foo2.o arm-linux-gnueabi-objdump -S a.out
With this sequence I get the following output:
0000000c<main>: c: b580 push {r7, lr} e: af00 add r7, sp, #0 10: f7ff fffe bl 18<foo> 14: 4618 mov r0, r3 16: bd80 pop {r7, pc}
00000018<foo>: 18: e92d0080 push {r7} 1c: e28d7000 add r7, sp, #0 20: e1a0d007 mov sp, r7 24: e8bd0080 pop {r7} 28: e12fff1e bx lr
Well, sure, but the result of "ld -r" is not a final executable, but just another relocatable object file. In particular, it will still carry relocation records. In fact, if you add --reloc to the objdump line, you should see:
Hmm. I was just trying to mimic the U-Boot link command there. Didn't really check what -r meant.
0000000c<main>: c: b580 push {r7, lr} e: af00 add r7, sp, #0 10: f7ff fffe bl 18<foo> 10: R_ARM_THM_CALL foo 14: 4618 mov r0, r3 16: bd80 pop {r7, pc}
The R_ARM_THM_CALL marks the branch instruction as still to be processed by the final link step. And once you actually *perform* the final link, e.g. via "gcc -o final a.out", the branch gets indeed converted to a blx by the linker for me:
This doesn't seem to be happening with U-boot. In U-boot, the situation is like this:
U-Boot builds multiple individual libraries and finally link them together. The call to the API and the weakly linked implementation is in one library(libarmv7.o), while the real implementation in assembly is in another library(libomap4.o). Here are the relevant contents of these libraries and the final image "u-boot" for your reference:
liarmv7.o: 000001b6 <arm_init_before_mmu>: }
void arm_init_before_mmu(void) { 1b6: b508 push {r3, lr} v7_outer_cache_enable(); 1b8: f7ff fffe bl 1f0 <__v7_outer_cache_enable> 1b8: R_ARM_THM_CALL v7_outer_cache_enable
libomap4.o: 0000111c <v7_outer_cache_enable>:
.globl v7_outer_cache_enable v7_outer_cache_enable: MOV r0, #1 111c: e3a00001 mov r0, #1 B set_pl310_ctrl_reg 1120: eafffff9 b 110c <set_pl310_ctrl_reg>
u-boot: void arm_init_before_mmu(void) { 80100636: b508 push {r3, lr} v7_outer_cache_enable(); 80100638: f001 f998 bl 8010196c <_end+0xfffaf2a4>
Here are the intermediate link commands used for the libraries: arm-linux-gnueabi-ld -r -o libarmv7.o cpu.o cache_v7.o syslib.o arm-linux-gnueabi-ld -r -o libomap4.o board.o mem.o sys_info.o ...
Here is the final link command(shortened and line-wrapped in the interest of readability - attaching the full build log): UNDEF_SYM=`arm-linux-gnueabi-objdump -x arch/arm/cpu/armv7/libarmv7.o arch/arm/cpu/armv7/omap4/libomap4.o arch/arm/lib/libarm.o | sed -n -e 's/.*(__u_boot_cmd_.*)/-u\1/p'|sort|uniq`; cd /home/a0393566local /u-boot-denx-bak && arm-linux-gnueabi-ld -pie -Bstatic -T u-boot.lds -Ttext 0x80100000 $UNDEF_SYM arch/arm/cpu/armv7/start.o --start-group arch/arm/cpu/armv7/libarmv7.o arch/arm/cpu/armv7/omap4/libomap4.o arch/arm/lib/libarm.o --end-group /home/a0393566local/u-boot-denx-bak /arch/arm/lib/eabi_compat.o -L /usr/lib/gcc/arm-linux-gnueabi/4.5.2 -lgcc -Map u-boot.map -o u-boot
I don't know what the UNDEF_SYM is about. Do you think that could be creating a problem?
This is now looking more like U-Boot build infrastructure issue. Maybe, I should take this up in the U-Boot mailing list now?
best regards, Aneesh