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<ane...@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.

regards,
Aneesh

Amicalement,
--
Albert.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to