mirror of
https://github.com/AsahiLinux/u-boot
synced 2024-11-28 15:41:40 +00:00
ARM: relocate: Fix Thumb code by using proper label type
The generic ARM relocate_code function was using its own function entry point as a relocation base, and it was obtaining that address by using the "adr" instruction on that entry point label. However that label is not just an ordinary label, instead we explicitly mark it as a function start address. Normally that doesn't change much (other than for debugging), but when assembled in Thumb mode, newer versions of the GNU assembler prepare everything for this address being used as the argument to a "bx" call, so make sure bit 0 is set in there to mark this function as Thumb code. Of course this doesn't end up very well when we use this address for the ensuing memcpy operation. To avoid this problem, and to solve it in a robust way, add an extra label, which is not marked as a function entry, and use that for the adr instruction. This lets all assemblers generate the right immediate offset in the "adr" instruction. This fixes in particular ARMv7-M ports when using GNU binutils v2.37 or newer (commit d3e52e120b68 seems to trigger the change in behaviour). Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reported-by: Jesse Taube <mr.bossman075@gmail.com>
This commit is contained in:
parent
86feeab3dc
commit
81e712a917
1 changed files with 2 additions and 1 deletions
|
@ -78,7 +78,8 @@ ENDPROC(relocate_vectors)
|
|||
*/
|
||||
|
||||
ENTRY(relocate_code)
|
||||
adr r3, relocate_code
|
||||
relocate_base:
|
||||
adr r3, relocate_base
|
||||
ldr r1, _image_copy_start_ofs
|
||||
add r1, r3 /* r1 <- Run &__image_copy_start */
|
||||
subs r4, r0, r1 /* r4 <- Run to copy offset */
|
||||
|
|
Loading…
Reference in a new issue