Aneesh V <ane...@ti.com> wrote:
> On Wednesday 16 March 2011 07:14 PM, Ulrich Weigand wrote:
> > 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 ...
Well, those aren't really "libraries" strictly speaking, since they
are build with "ld -r", so they're actually just regular object files.
But that doesn't really matter one way or the other ...
> 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?
I can't see how ... this just adds a bunch of undefined symbols via -u
options, which presumably causes some objects to be pulled into the
final link that otherwise wouldn't be.
I've tried to recreate the problem using the specific linker options
(-pie and -Bstatic), but that didn't make any difference for me; it
still resolved the branch to a blx.
> This is now looking more like U-Boot build infrastructure issue. Maybe,
> I should take this up in the U-Boot mailing list now?
I can see two options here: either there's something weird going on in
one of the parts I cannot reproduce, or else there's some bug in the
version of the linker you're using. So I'm wondering:
- Can you send me the full set of files (.o files, u-boot.lds linker
script, exact full command line etc.) for me to be able to run the
actual link command myself?
- What version of the linker are you using? Can you retry the link
on a native ARM Ubuntu Natty system using the system linker?
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
