[U-Boot] [PATCH 2/4] arm: add %function attribute to assembly functions

[Albert ARIBAUD]

Hi Aneesh,

Le 18/02/2012 14:24, Aneesh V a écrit :
> Hi Albert,
>
> On Saturday 18 February 2012 03:43 PM, Albert ARIBAUD wrote:
>> Hi Aneesh,
>>
>> Le 17/02/2012 12:09, Aneesh V a écrit :
>>> Hi Albert,
>>>
>>> On Wednesday 15 February 2012 07:27 PM, Aneesh V wrote:
>>>> This is done using the following directive preceding
>>>> each function definition:
>>>>
>>>> .type<func-name>, %function
>>>>
>>>> This marks the symbol as a function in the object
>>>> header which in turn helps the linker in some cases.
>>>>
>>>> In particular this was found needed for resolving ARM/Thumb
>>>> calls correctly in a build with Thumb interworking enabled.
>>>>
>>>> This solves the following problem I had reported earlier:
>>>>
>>>> "When U-Boot/SPL is built using the Thumb instruction set the
>>>> toolchain has a potential issue with weakly linked symbols.
>>>> If a function has a weakly linked default implementation in C
>>>> and a real implementation in assembly GCC is confused about the
>>>> instruction set of the assembly implementation. As a result
>>>> the assembly function that is built in ARM is executed as
>>>> if it is Thumb. This results in a crash"
>>>>
>>>> Signed-off-by: Aneesh V<aneesh at ti.com>
>>>
>>> Does this look good to you. I was a bit nervous about touching so many
>>> files. Please let me know if you would prefer to change only the OMAP
>>> function that was creating the ARM/Thumb problem. I did a "MAKEALL -a
>>> arm" and didn't see any new errors.
>>>
>>> Let me know if this is an acceptable solution to the problem.
>>
>> Regarding the solution: it is quite ok to me. I would just like to
>> understand the exact effect of the .function directive, what its options
>> are and if some of these should not be explicitly specified.
>>
>> Regarding touching many files: I won't be worried as long as you check
>> that the first three patches have no effect on existing boards. This can
>> be verified as follows -- if you haven't done so already:
>>
>> - build your OMAP target without the patch set and do a hex dump of
>> u-boot.bin;
>>
>> - apply the first three patches of your set, rebuild your OMAP target
>> without the patch set and do a hex dump of u-boot.bin;
>>
>> - compare both dumps. Normally you should only see one difference, in
>> the build version and date -- if .function does not actually alter the
>> assembly code, which I hope it indeed does not when building for ARM.
>>
>> If there are more changes than build version and date, then they might
>> be due to .function requiring some yet unknown additional option, or to
>> some change in patch 1 or 3 not being completely conditioned on
>> CONFIG_SYS_THUMB_BUILD.
>
> I can reproduce the problem with a simple test program.
> Note: I can reproduce this with Sourcery G++ Lite 2010q1-202 (GCC 4.4.1
> - Binutils 2.19.51.20090709)
> But I *can not* reproduce reproduce this with Linaro GCC 2012.01 (GCC
> 4.6.3 , Binutils 2.22)
> So apparently the issue has been fixed recently. Unfortunately Linaro
> GCC 2012.01 creates a new Thumb problem that I am investigating now.
> Somehow I missed this when I tested earlier. So, my Thumb build is
> not working with Linaro GCC 2012.01. But this one is not reproduced on
> Sourcery G++ Lite 2010q1-202!
>
> Here is the program I used to reproduce the problem in Sourcery G++
> Lite 2010q1-202 that this patch is addressing
>
> a.c:
> ====
> extern void foo (void) __attribute__ ((weak, alias ("__foo")));
>
> void __foo (void)
> {
> }
>
> extern void call_foo(void);
>
> int main (void)
> {
> call_foo ();
> }
>
> b.S:
> ====
> .text
> .align 2
> .global foo
> foo:
> push {r7}
> add r7, sp, #0
> mov sp, r7
> pop {r7}
> bx lr
> .size foo, .-foo
>
>
> c.S:
> ====
> .text
> .align 2
>
> .global call_foo
> call_foo:
> bl foo
> bx lr
>
> .global __aeabi_unwind_cpp_pr0
> __aeabi_unwind_cpp_pr0:
> bx lr
>
> Now build it and take the assembly dump using the following commands:
>
> arm-none-linux-gnueabi-gcc -mthumb -mthumb-interwork -c a.c
> arm-none-linux-gnueabi-gcc -mthumb -mthumb-interwork -c b.S
> arm-none-linux-gnueabi-gcc -mthumb -mthumb-interwork -c c.S
> arm-none-linux-gnueabi-ld -r a.o -o alib.o
> arm-none-linux-gnueabi-ld -r b.o -o blib.o
> arm-none-linux-gnueabi-ld -r c.o -o clib.o
> arm-none-linux-gnueabi-ld --start-group clib.o alib.o blib.o --end-group
> -o a.out
> arm-none-linux-gnueabi-objdump -S --reloc a.out
>
> You will get something like this in the assembly dump:
> 00008094 <call_foo>:
> 8094: fa000006 blx 80b4 <foo>
> 8098: e12fff1e bx lr
>
> The blx is wrong as we are jumping to an ARM function from ARM.
>
> Now if you change b.S like this:
>
> .text
> .align 2
> +.type foo, %function
> .global foo
> foo:
> push {r7}
>
>
> And compile it again in the same way you will see:
> 00008094 <call_foo>:
> 8094: eb000006 bl 80b4 <foo>
> 8098: e12fff1e bx lr
>
> Please note that the branch to foo is correct now.
>
> I hope this convinces you that %function indeed has an effect.

This convinces me that .function as you used it had the effect that you 
needed for Thumb compilation, but I had no doubts about that. What I 
want to be sure is that it also has no other, unexpected, effect, 
especially when still building ARM code only; and the test I suggest 
would demonstrate this. :)

> I will get back with more details on the Linaro GCC 2012.01 later.

Thanks. Anyway, this patch series is not going to end up in 2012.03 so 
there is no hurry and we can take our time making sure it works well.

> br,
> Aneesh

Amicalement,
-- 
Albert.