gcc: Thumb interworking and weakly linked functions

[Aneesh V]

Hi Ulrich,

On Tuesday 15 March 2011 09:00 PM, Ulrich Weigand wrote:
> Aneesh V<aneesh at ti.com>  wrote:
>
>> I was trying to build u-boot in Thumb2 for OMAP4. Everything was fine
>> until I added some patches recently. One of these patches introduced an
>> API (let's say foo()) that has a weakly linked alias(let's say
>> __foo()) and a strongly linked implementation(the real foo()) in an
>> assembly file.
>>
>> Although I give -mthumb and -mthumb-interwork for all the files,
>> apparently GCC generates ARM code for assembly files. In the final
>> image foobar() calls foo() using a BL. Since foobar() is in Thumb and
>> foo() in ARM, it ends up crashing. Looks like foobar() assumed foo()
>> to be Thumb because __foo() is Thumb.
>
> I'm unable to reproduce this.  Do you have a complete test case?

Thank you for looking into this problem.

>
> I've tried with the following small example:
>
> foo1.c:
>
> extern void foo (void) __attribute__ ((weak, alias ("__foo")));
>
> void __foo (void)
> {
> }
>
> int main (void)
> {
>    foo ();
> }
>
> foo2.S:
>          .text
>          .align  2
>          .global foo
>          .type   foo, %function
> foo:
>          push    {r7}
>          add     r7, sp, #0
>          mov     sp, r7
>          pop     {r7}
>          bx      lr
>          .size   foo, .-foo
>

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:

00000000 <__foo>:
    0:	b480      	push	{r7}
    2:	af00      	add	r7, sp, #0
    4:	46bd      	mov	sp, r7
    6:	bc80      	pop	{r7}
    8:	4770      	bx	lr
    a:	bf00      	nop

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

> When building just "gcc foo1.c", I get:
>
> 0000835c<__foo>:
>      835c:       b480            push    {r7}
>      835e:       af00            add     r7, sp, #0
>      8360:       46bd            mov     sp, r7
>      8362:       bc80            pop     {r7}
>      8364:       4770            bx      lr
>      8366:       bf00            nop
>
> 00008368<main>:
>      8368:       b580            push    {r7, lr}
>      836a:       af00            add     r7, sp, #0
>      836c:       f7ff fff6       bl      835c<__foo>
>      8370:       4618            mov     r0, r3
>      8372:       bd80            pop     {r7, pc}
>
> When building both files "gcc foo1.c foo2.S", I get instead:
>
> 00008368<main>:
>      8368:       b580            push    {r7, lr}
>      836a:       af00            add     r7, sp, #0
>      836c:       f000 e802       blx     8374<foo>
>      8370:       4618            mov     r0, r3
>      8372:       bd80            pop     {r7, pc}
>
> 00008374<foo>:
>      8374:       e92d0080        push    {r7}
>      8378:       e28d7000        add     r7, sp, #0
>      837c:       e1a0d007        mov     sp, r7
>      8380:       e8bd0080        pop     {r7}
>      8384:       e12fff1e        bx      lr
>
>
> So it seems to me the linker is handling this correctly ...
>
> (This is on Ubuntu Natty using system gcc and binutils.)
>
>
>
> 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
>