On Mon, Aug 13, 2012 at 5:36 PM, Allen Martin <amar...@nvidia.com> wrote: > On Mon, Aug 13, 2012 at 04:44:05PM -0700, Stephen Warren wrote: >> On 08/01/2012 02:32 PM, Allen Martin wrote: >> > Add function required by some thumb switch statements >> >> > diff --git a/arch/arm/lib/_thumb1_case_uqi.S >> > b/arch/arm/lib/_thumb1_case_uqi.S >> >> > + .force_thumb >> >> I believe that line should be removed. >> >> The issue here is that when gcc emits Thumb code to call this function, >> it actually emits: >> >> > 108af8: f000 f94a bl 108d90 >> > <____gnu_thumb1_case_uqi_from_thumb> >> >> which is implemented as: >> >> > 00108d90 <____gnu_thumb1_case_uqi_from_thumb>: >> > 108d90: 4778 bx pc >> > 108d92: 46c0 nop ; (mov r8, r8) >> > 108d94: eafffde1 b 108520 <__gnu_thumb1_case_uqi> >> >> i.e. it switches to ARM mode then jumps to that function. Hence, >> __gnu_thumb1_case_uqi must be compiled as ARM, not as Thumb. > > The function is supposed to be thumb code, it's basically a thumb > optimization of a switch statement, and in the ARM case the compiler > just emits the code directly instead of calling into libgcc. So it > doesn't really make sense for the function to be anything but thumb. > > I think the real problem is the linker incorrectly thought the code > was ARM so it generated a thumb to ARM interworking veneer. > > Can you try adding a ".type __gnu_thumb1_case_uqi STT_FUNC" instead? > I've seen cases where the assembler generates the wrong type of symbol > without some explicit guidance which messes up the linker's > interworking generator. This might be one of those.
Yes, not having STT_FUNC or %function is troublesome. I have faced this before. Maybe you should wrap the assembly functions with standard ENTRY, END_PROC macros from linkage.h. This will take care of STT_FUNC best regards, Aneesh _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
