2019-06-04 11:11:33 +03:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-only */
|
2005-11-01 22:52:23 +03:00
|
|
|
/*
|
|
|
|
* linux/arch/arm/lib/memmove.S
|
|
|
|
*
|
|
|
|
* Author: Nicolas Pitre
|
|
|
|
* Created: Sep 28, 2005
|
|
|
|
* Copyright: (C) MontaVista Software Inc.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/linkage.h>
|
|
|
|
#include <asm/assembler.h>
|
2014-11-26 16:36:15 +03:00
|
|
|
#include <asm/unwind.h>
|
2005-11-01 22:52:23 +03:00
|
|
|
|
|
|
|
.text
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Prototype: void *memmove(void *dest, const void *src, size_t n);
|
|
|
|
*
|
|
|
|
* Note:
|
|
|
|
*
|
|
|
|
* If the memory regions don't overlap, we simply branch to memcpy which is
|
|
|
|
* normally a bit faster. Otherwise the copy is done going downwards. This
|
|
|
|
* is a transposition of the code from copy_template.S but with the copy
|
|
|
|
* occurring in the opposite direction.
|
|
|
|
*/
|
|
|
|
|
2020-10-26 01:52:08 +03:00
|
|
|
ENTRY(__memmove)
|
2020-11-06 23:46:11 +03:00
|
|
|
WEAK(memmove)
|
2014-11-26 16:36:15 +03:00
|
|
|
UNWIND( .fnstart )
|
2005-11-01 22:52:23 +03:00
|
|
|
|
|
|
|
subs ip, r0, r1
|
|
|
|
cmphi r2, ip
|
2020-10-26 01:52:08 +03:00
|
|
|
bls __memcpy
|
2014-11-26 16:36:15 +03:00
|
|
|
UNWIND( .fnend )
|
|
|
|
|
|
|
|
UNWIND( .fnstart )
|
ARM: memmove: use frame pointer as unwind anchor
The memmove routine is a bit unusual in the way it manages the stack
pointer: depending on the execution path through the function, the SP
assumes different values as different subsets of the register file are
preserved and restored again. This is problematic when it comes to EHABI
unwind info, as it is not instruction accurate, and does not allow
tracking the SP value as it changes.
Commit 207a6cb06990c ("ARM: 8224/1: Add unwinding support for memmove
function") addressed this by carving up the function in different chunks
as far as the unwinder is concerned, and keeping a set of unwind
directives for each of them, each corresponding with the state of the
stack pointer during execution of the chunk in question. This not only
duplicates unwind info unnecessarily, but it also complicates unwinding
the stack upon overflow.
Instead, let's do what the compiler does when the SP is updated halfway
through a function, which is to use a frame pointer and emit the
appropriate unwind directives to communicate this to the unwinder.
Note that Thumb-2 uses R7 for this, while ARM uses R11 aka FP. So let's
avoid touching R7 in the body of the function, so that Thumb-2 can use
it as the frame pointer. R11 was not modified in the first place.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Keith Packard <keithpac@amazon.com>
Tested-by: Marc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
2021-10-04 12:29:11 +03:00
|
|
|
UNWIND( .save {r0, r4, fpreg, lr} )
|
|
|
|
stmfd sp!, {r0, r4, UNWIND(fpreg,) lr}
|
|
|
|
UNWIND( .setfp fpreg, sp )
|
|
|
|
UNWIND( mov fpreg, sp )
|
2005-11-01 22:52:23 +03:00
|
|
|
add r1, r1, r2
|
|
|
|
add r0, r0, r2
|
|
|
|
subs r2, r2, #4
|
|
|
|
blt 8f
|
|
|
|
ands ip, r0, #3
|
|
|
|
PLD( pld [r1, #-4] )
|
|
|
|
bne 9f
|
|
|
|
ands ip, r1, #3
|
|
|
|
bne 10f
|
|
|
|
|
|
|
|
1: subs r2, r2, #(28)
|
ARM: memmove: use frame pointer as unwind anchor
The memmove routine is a bit unusual in the way it manages the stack
pointer: depending on the execution path through the function, the SP
assumes different values as different subsets of the register file are
preserved and restored again. This is problematic when it comes to EHABI
unwind info, as it is not instruction accurate, and does not allow
tracking the SP value as it changes.
Commit 207a6cb06990c ("ARM: 8224/1: Add unwinding support for memmove
function") addressed this by carving up the function in different chunks
as far as the unwinder is concerned, and keeping a set of unwind
directives for each of them, each corresponding with the state of the
stack pointer during execution of the chunk in question. This not only
duplicates unwind info unnecessarily, but it also complicates unwinding
the stack upon overflow.
Instead, let's do what the compiler does when the SP is updated halfway
through a function, which is to use a frame pointer and emit the
appropriate unwind directives to communicate this to the unwinder.
Note that Thumb-2 uses R7 for this, while ARM uses R11 aka FP. So let's
avoid touching R7 in the body of the function, so that Thumb-2 can use
it as the frame pointer. R11 was not modified in the first place.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Keith Packard <keithpac@amazon.com>
Tested-by: Marc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
2021-10-04 12:29:11 +03:00
|
|
|
stmfd sp!, {r5, r6, r8, r9}
|
2005-11-01 22:52:23 +03:00
|
|
|
blt 5f
|
|
|
|
|
2008-03-31 20:38:31 +04:00
|
|
|
CALGN( ands ip, r0, #31 )
|
2019-02-18 02:57:38 +03:00
|
|
|
CALGN( sbcsne r4, ip, r2 ) @ C is always set here
|
2005-11-01 22:52:23 +03:00
|
|
|
CALGN( bcs 2f )
|
|
|
|
CALGN( adr r4, 6f )
|
|
|
|
CALGN( subs r2, r2, ip ) @ C is set here
|
2008-06-11 20:40:13 +04:00
|
|
|
CALGN( rsb ip, ip, #32 )
|
2005-11-01 22:52:23 +03:00
|
|
|
CALGN( add pc, r4, ip )
|
|
|
|
|
|
|
|
PLD( pld [r1, #-4] )
|
|
|
|
2: PLD( subs r2, r2, #96 )
|
|
|
|
PLD( pld [r1, #-32] )
|
|
|
|
PLD( blt 4f )
|
|
|
|
PLD( pld [r1, #-64] )
|
|
|
|
PLD( pld [r1, #-96] )
|
|
|
|
|
|
|
|
3: PLD( pld [r1, #-128] )
|
ARM: memmove: use frame pointer as unwind anchor
The memmove routine is a bit unusual in the way it manages the stack
pointer: depending on the execution path through the function, the SP
assumes different values as different subsets of the register file are
preserved and restored again. This is problematic when it comes to EHABI
unwind info, as it is not instruction accurate, and does not allow
tracking the SP value as it changes.
Commit 207a6cb06990c ("ARM: 8224/1: Add unwinding support for memmove
function") addressed this by carving up the function in different chunks
as far as the unwinder is concerned, and keeping a set of unwind
directives for each of them, each corresponding with the state of the
stack pointer during execution of the chunk in question. This not only
duplicates unwind info unnecessarily, but it also complicates unwinding
the stack upon overflow.
Instead, let's do what the compiler does when the SP is updated halfway
through a function, which is to use a frame pointer and emit the
appropriate unwind directives to communicate this to the unwinder.
Note that Thumb-2 uses R7 for this, while ARM uses R11 aka FP. So let's
avoid touching R7 in the body of the function, so that Thumb-2 can use
it as the frame pointer. R11 was not modified in the first place.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Keith Packard <keithpac@amazon.com>
Tested-by: Marc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
2021-10-04 12:29:11 +03:00
|
|
|
4: ldmdb r1!, {r3, r4, r5, r6, r8, r9, ip, lr}
|
2005-11-01 22:52:23 +03:00
|
|
|
subs r2, r2, #32
|
ARM: memmove: use frame pointer as unwind anchor
The memmove routine is a bit unusual in the way it manages the stack
pointer: depending on the execution path through the function, the SP
assumes different values as different subsets of the register file are
preserved and restored again. This is problematic when it comes to EHABI
unwind info, as it is not instruction accurate, and does not allow
tracking the SP value as it changes.
Commit 207a6cb06990c ("ARM: 8224/1: Add unwinding support for memmove
function") addressed this by carving up the function in different chunks
as far as the unwinder is concerned, and keeping a set of unwind
directives for each of them, each corresponding with the state of the
stack pointer during execution of the chunk in question. This not only
duplicates unwind info unnecessarily, but it also complicates unwinding
the stack upon overflow.
Instead, let's do what the compiler does when the SP is updated halfway
through a function, which is to use a frame pointer and emit the
appropriate unwind directives to communicate this to the unwinder.
Note that Thumb-2 uses R7 for this, while ARM uses R11 aka FP. So let's
avoid touching R7 in the body of the function, so that Thumb-2 can use
it as the frame pointer. R11 was not modified in the first place.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Keith Packard <keithpac@amazon.com>
Tested-by: Marc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
2021-10-04 12:29:11 +03:00
|
|
|
stmdb r0!, {r3, r4, r5, r6, r8, r9, ip, lr}
|
2005-11-01 22:52:23 +03:00
|
|
|
bge 3b
|
|
|
|
PLD( cmn r2, #96 )
|
|
|
|
PLD( bge 4b )
|
|
|
|
|
|
|
|
5: ands ip, r2, #28
|
|
|
|
rsb ip, ip, #32
|
|
|
|
addne pc, pc, ip @ C is always clear here
|
|
|
|
b 7f
|
2010-03-29 13:29:46 +04:00
|
|
|
6: W(nop)
|
2009-07-24 15:32:57 +04:00
|
|
|
W(ldr) r3, [r1, #-4]!
|
|
|
|
W(ldr) r4, [r1, #-4]!
|
|
|
|
W(ldr) r5, [r1, #-4]!
|
|
|
|
W(ldr) r6, [r1, #-4]!
|
|
|
|
W(ldr) r8, [r1, #-4]!
|
ARM: memmove: use frame pointer as unwind anchor
The memmove routine is a bit unusual in the way it manages the stack
pointer: depending on the execution path through the function, the SP
assumes different values as different subsets of the register file are
preserved and restored again. This is problematic when it comes to EHABI
unwind info, as it is not instruction accurate, and does not allow
tracking the SP value as it changes.
Commit 207a6cb06990c ("ARM: 8224/1: Add unwinding support for memmove
function") addressed this by carving up the function in different chunks
as far as the unwinder is concerned, and keeping a set of unwind
directives for each of them, each corresponding with the state of the
stack pointer during execution of the chunk in question. This not only
duplicates unwind info unnecessarily, but it also complicates unwinding
the stack upon overflow.
Instead, let's do what the compiler does when the SP is updated halfway
through a function, which is to use a frame pointer and emit the
appropriate unwind directives to communicate this to the unwinder.
Note that Thumb-2 uses R7 for this, while ARM uses R11 aka FP. So let's
avoid touching R7 in the body of the function, so that Thumb-2 can use
it as the frame pointer. R11 was not modified in the first place.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Keith Packard <keithpac@amazon.com>
Tested-by: Marc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
2021-10-04 12:29:11 +03:00
|
|
|
W(ldr) r9, [r1, #-4]!
|
2009-07-24 15:32:57 +04:00
|
|
|
W(ldr) lr, [r1, #-4]!
|
2005-11-01 22:52:23 +03:00
|
|
|
|
|
|
|
add pc, pc, ip
|
|
|
|
nop
|
2010-03-29 13:29:46 +04:00
|
|
|
W(nop)
|
2009-07-24 15:32:57 +04:00
|
|
|
W(str) r3, [r0, #-4]!
|
|
|
|
W(str) r4, [r0, #-4]!
|
|
|
|
W(str) r5, [r0, #-4]!
|
|
|
|
W(str) r6, [r0, #-4]!
|
|
|
|
W(str) r8, [r0, #-4]!
|
ARM: memmove: use frame pointer as unwind anchor
The memmove routine is a bit unusual in the way it manages the stack
pointer: depending on the execution path through the function, the SP
assumes different values as different subsets of the register file are
preserved and restored again. This is problematic when it comes to EHABI
unwind info, as it is not instruction accurate, and does not allow
tracking the SP value as it changes.
Commit 207a6cb06990c ("ARM: 8224/1: Add unwinding support for memmove
function") addressed this by carving up the function in different chunks
as far as the unwinder is concerned, and keeping a set of unwind
directives for each of them, each corresponding with the state of the
stack pointer during execution of the chunk in question. This not only
duplicates unwind info unnecessarily, but it also complicates unwinding
the stack upon overflow.
Instead, let's do what the compiler does when the SP is updated halfway
through a function, which is to use a frame pointer and emit the
appropriate unwind directives to communicate this to the unwinder.
Note that Thumb-2 uses R7 for this, while ARM uses R11 aka FP. So let's
avoid touching R7 in the body of the function, so that Thumb-2 can use
it as the frame pointer. R11 was not modified in the first place.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Keith Packard <keithpac@amazon.com>
Tested-by: Marc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
2021-10-04 12:29:11 +03:00
|
|
|
W(str) r9, [r0, #-4]!
|
2009-07-24 15:32:57 +04:00
|
|
|
W(str) lr, [r0, #-4]!
|
2005-11-01 22:52:23 +03:00
|
|
|
|
|
|
|
CALGN( bcs 2b )
|
|
|
|
|
ARM: memmove: use frame pointer as unwind anchor
The memmove routine is a bit unusual in the way it manages the stack
pointer: depending on the execution path through the function, the SP
assumes different values as different subsets of the register file are
preserved and restored again. This is problematic when it comes to EHABI
unwind info, as it is not instruction accurate, and does not allow
tracking the SP value as it changes.
Commit 207a6cb06990c ("ARM: 8224/1: Add unwinding support for memmove
function") addressed this by carving up the function in different chunks
as far as the unwinder is concerned, and keeping a set of unwind
directives for each of them, each corresponding with the state of the
stack pointer during execution of the chunk in question. This not only
duplicates unwind info unnecessarily, but it also complicates unwinding
the stack upon overflow.
Instead, let's do what the compiler does when the SP is updated halfway
through a function, which is to use a frame pointer and emit the
appropriate unwind directives to communicate this to the unwinder.
Note that Thumb-2 uses R7 for this, while ARM uses R11 aka FP. So let's
avoid touching R7 in the body of the function, so that Thumb-2 can use
it as the frame pointer. R11 was not modified in the first place.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Keith Packard <keithpac@amazon.com>
Tested-by: Marc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
2021-10-04 12:29:11 +03:00
|
|
|
7: ldmfd sp!, {r5, r6, r8, r9}
|
2005-11-01 22:52:23 +03:00
|
|
|
|
|
|
|
8: movs r2, r2, lsl #31
|
2019-02-18 02:57:38 +03:00
|
|
|
ldrbne r3, [r1, #-1]!
|
|
|
|
ldrbcs r4, [r1, #-1]!
|
|
|
|
ldrbcs ip, [r1, #-1]
|
|
|
|
strbne r3, [r0, #-1]!
|
|
|
|
strbcs r4, [r0, #-1]!
|
|
|
|
strbcs ip, [r0, #-1]
|
ARM: memmove: use frame pointer as unwind anchor
The memmove routine is a bit unusual in the way it manages the stack
pointer: depending on the execution path through the function, the SP
assumes different values as different subsets of the register file are
preserved and restored again. This is problematic when it comes to EHABI
unwind info, as it is not instruction accurate, and does not allow
tracking the SP value as it changes.
Commit 207a6cb06990c ("ARM: 8224/1: Add unwinding support for memmove
function") addressed this by carving up the function in different chunks
as far as the unwinder is concerned, and keeping a set of unwind
directives for each of them, each corresponding with the state of the
stack pointer during execution of the chunk in question. This not only
duplicates unwind info unnecessarily, but it also complicates unwinding
the stack upon overflow.
Instead, let's do what the compiler does when the SP is updated halfway
through a function, which is to use a frame pointer and emit the
appropriate unwind directives to communicate this to the unwinder.
Note that Thumb-2 uses R7 for this, while ARM uses R11 aka FP. So let's
avoid touching R7 in the body of the function, so that Thumb-2 can use
it as the frame pointer. R11 was not modified in the first place.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Keith Packard <keithpac@amazon.com>
Tested-by: Marc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
2021-10-04 12:29:11 +03:00
|
|
|
ldmfd sp!, {r0, r4, UNWIND(fpreg,) pc}
|
2005-11-01 22:52:23 +03:00
|
|
|
|
|
|
|
9: cmp ip, #2
|
2019-02-18 02:57:38 +03:00
|
|
|
ldrbgt r3, [r1, #-1]!
|
|
|
|
ldrbge r4, [r1, #-1]!
|
2005-11-01 22:52:23 +03:00
|
|
|
ldrb lr, [r1, #-1]!
|
2019-02-18 02:57:38 +03:00
|
|
|
strbgt r3, [r0, #-1]!
|
|
|
|
strbge r4, [r0, #-1]!
|
2005-11-01 22:52:23 +03:00
|
|
|
subs r2, r2, ip
|
|
|
|
strb lr, [r0, #-1]!
|
|
|
|
blt 8b
|
|
|
|
ands ip, r1, #3
|
|
|
|
beq 1b
|
|
|
|
|
|
|
|
10: bic r1, r1, #3
|
|
|
|
cmp ip, #2
|
|
|
|
ldr r3, [r1, #0]
|
|
|
|
beq 17f
|
|
|
|
blt 18f
|
|
|
|
|
|
|
|
|
|
|
|
.macro backward_copy_shift push pull
|
|
|
|
|
|
|
|
subs r2, r2, #28
|
|
|
|
blt 14f
|
|
|
|
|
2008-03-31 20:38:31 +04:00
|
|
|
CALGN( ands ip, r0, #31 )
|
2019-02-18 02:57:38 +03:00
|
|
|
CALGN( sbcsne r4, ip, r2 ) @ C is always set here
|
2005-11-01 22:52:23 +03:00
|
|
|
CALGN( subcc r2, r2, ip )
|
|
|
|
CALGN( bcc 15f )
|
|
|
|
|
ARM: memmove: use frame pointer as unwind anchor
The memmove routine is a bit unusual in the way it manages the stack
pointer: depending on the execution path through the function, the SP
assumes different values as different subsets of the register file are
preserved and restored again. This is problematic when it comes to EHABI
unwind info, as it is not instruction accurate, and does not allow
tracking the SP value as it changes.
Commit 207a6cb06990c ("ARM: 8224/1: Add unwinding support for memmove
function") addressed this by carving up the function in different chunks
as far as the unwinder is concerned, and keeping a set of unwind
directives for each of them, each corresponding with the state of the
stack pointer during execution of the chunk in question. This not only
duplicates unwind info unnecessarily, but it also complicates unwinding
the stack upon overflow.
Instead, let's do what the compiler does when the SP is updated halfway
through a function, which is to use a frame pointer and emit the
appropriate unwind directives to communicate this to the unwinder.
Note that Thumb-2 uses R7 for this, while ARM uses R11 aka FP. So let's
avoid touching R7 in the body of the function, so that Thumb-2 can use
it as the frame pointer. R11 was not modified in the first place.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Keith Packard <keithpac@amazon.com>
Tested-by: Marc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
2021-10-04 12:29:11 +03:00
|
|
|
11: stmfd sp!, {r5, r6, r8 - r10}
|
2005-11-01 22:52:23 +03:00
|
|
|
|
|
|
|
PLD( pld [r1, #-4] )
|
|
|
|
PLD( subs r2, r2, #96 )
|
|
|
|
PLD( pld [r1, #-32] )
|
|
|
|
PLD( blt 13f )
|
|
|
|
PLD( pld [r1, #-64] )
|
|
|
|
PLD( pld [r1, #-96] )
|
|
|
|
|
|
|
|
12: PLD( pld [r1, #-128] )
|
ARM: memmove: use frame pointer as unwind anchor
The memmove routine is a bit unusual in the way it manages the stack
pointer: depending on the execution path through the function, the SP
assumes different values as different subsets of the register file are
preserved and restored again. This is problematic when it comes to EHABI
unwind info, as it is not instruction accurate, and does not allow
tracking the SP value as it changes.
Commit 207a6cb06990c ("ARM: 8224/1: Add unwinding support for memmove
function") addressed this by carving up the function in different chunks
as far as the unwinder is concerned, and keeping a set of unwind
directives for each of them, each corresponding with the state of the
stack pointer during execution of the chunk in question. This not only
duplicates unwind info unnecessarily, but it also complicates unwinding
the stack upon overflow.
Instead, let's do what the compiler does when the SP is updated halfway
through a function, which is to use a frame pointer and emit the
appropriate unwind directives to communicate this to the unwinder.
Note that Thumb-2 uses R7 for this, while ARM uses R11 aka FP. So let's
avoid touching R7 in the body of the function, so that Thumb-2 can use
it as the frame pointer. R11 was not modified in the first place.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Keith Packard <keithpac@amazon.com>
Tested-by: Marc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
2021-10-04 12:29:11 +03:00
|
|
|
13: ldmdb r1!, {r8, r9, r10, ip}
|
2014-02-25 11:41:09 +04:00
|
|
|
mov lr, r3, lspush #\push
|
2005-11-01 22:52:23 +03:00
|
|
|
subs r2, r2, #32
|
|
|
|
ldmdb r1!, {r3, r4, r5, r6}
|
2014-02-25 11:41:09 +04:00
|
|
|
orr lr, lr, ip, lspull #\pull
|
|
|
|
mov ip, ip, lspush #\push
|
ARM: memmove: use frame pointer as unwind anchor
The memmove routine is a bit unusual in the way it manages the stack
pointer: depending on the execution path through the function, the SP
assumes different values as different subsets of the register file are
preserved and restored again. This is problematic when it comes to EHABI
unwind info, as it is not instruction accurate, and does not allow
tracking the SP value as it changes.
Commit 207a6cb06990c ("ARM: 8224/1: Add unwinding support for memmove
function") addressed this by carving up the function in different chunks
as far as the unwinder is concerned, and keeping a set of unwind
directives for each of them, each corresponding with the state of the
stack pointer during execution of the chunk in question. This not only
duplicates unwind info unnecessarily, but it also complicates unwinding
the stack upon overflow.
Instead, let's do what the compiler does when the SP is updated halfway
through a function, which is to use a frame pointer and emit the
appropriate unwind directives to communicate this to the unwinder.
Note that Thumb-2 uses R7 for this, while ARM uses R11 aka FP. So let's
avoid touching R7 in the body of the function, so that Thumb-2 can use
it as the frame pointer. R11 was not modified in the first place.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Keith Packard <keithpac@amazon.com>
Tested-by: Marc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
2021-10-04 12:29:11 +03:00
|
|
|
orr ip, ip, r10, lspull #\pull
|
|
|
|
mov r10, r10, lspush #\push
|
|
|
|
orr r10, r10, r9, lspull #\pull
|
2014-02-25 11:41:09 +04:00
|
|
|
mov r9, r9, lspush #\push
|
|
|
|
orr r9, r9, r8, lspull #\pull
|
|
|
|
mov r8, r8, lspush #\push
|
ARM: memmove: use frame pointer as unwind anchor
The memmove routine is a bit unusual in the way it manages the stack
pointer: depending on the execution path through the function, the SP
assumes different values as different subsets of the register file are
preserved and restored again. This is problematic when it comes to EHABI
unwind info, as it is not instruction accurate, and does not allow
tracking the SP value as it changes.
Commit 207a6cb06990c ("ARM: 8224/1: Add unwinding support for memmove
function") addressed this by carving up the function in different chunks
as far as the unwinder is concerned, and keeping a set of unwind
directives for each of them, each corresponding with the state of the
stack pointer during execution of the chunk in question. This not only
duplicates unwind info unnecessarily, but it also complicates unwinding
the stack upon overflow.
Instead, let's do what the compiler does when the SP is updated halfway
through a function, which is to use a frame pointer and emit the
appropriate unwind directives to communicate this to the unwinder.
Note that Thumb-2 uses R7 for this, while ARM uses R11 aka FP. So let's
avoid touching R7 in the body of the function, so that Thumb-2 can use
it as the frame pointer. R11 was not modified in the first place.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Keith Packard <keithpac@amazon.com>
Tested-by: Marc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
2021-10-04 12:29:11 +03:00
|
|
|
orr r8, r8, r6, lspull #\pull
|
2014-02-25 11:41:09 +04:00
|
|
|
mov r6, r6, lspush #\push
|
|
|
|
orr r6, r6, r5, lspull #\pull
|
|
|
|
mov r5, r5, lspush #\push
|
|
|
|
orr r5, r5, r4, lspull #\pull
|
|
|
|
mov r4, r4, lspush #\push
|
|
|
|
orr r4, r4, r3, lspull #\pull
|
ARM: memmove: use frame pointer as unwind anchor
The memmove routine is a bit unusual in the way it manages the stack
pointer: depending on the execution path through the function, the SP
assumes different values as different subsets of the register file are
preserved and restored again. This is problematic when it comes to EHABI
unwind info, as it is not instruction accurate, and does not allow
tracking the SP value as it changes.
Commit 207a6cb06990c ("ARM: 8224/1: Add unwinding support for memmove
function") addressed this by carving up the function in different chunks
as far as the unwinder is concerned, and keeping a set of unwind
directives for each of them, each corresponding with the state of the
stack pointer during execution of the chunk in question. This not only
duplicates unwind info unnecessarily, but it also complicates unwinding
the stack upon overflow.
Instead, let's do what the compiler does when the SP is updated halfway
through a function, which is to use a frame pointer and emit the
appropriate unwind directives to communicate this to the unwinder.
Note that Thumb-2 uses R7 for this, while ARM uses R11 aka FP. So let's
avoid touching R7 in the body of the function, so that Thumb-2 can use
it as the frame pointer. R11 was not modified in the first place.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Keith Packard <keithpac@amazon.com>
Tested-by: Marc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
2021-10-04 12:29:11 +03:00
|
|
|
stmdb r0!, {r4 - r6, r8 - r10, ip, lr}
|
2005-11-01 22:52:23 +03:00
|
|
|
bge 12b
|
|
|
|
PLD( cmn r2, #96 )
|
|
|
|
PLD( bge 13b )
|
|
|
|
|
ARM: memmove: use frame pointer as unwind anchor
The memmove routine is a bit unusual in the way it manages the stack
pointer: depending on the execution path through the function, the SP
assumes different values as different subsets of the register file are
preserved and restored again. This is problematic when it comes to EHABI
unwind info, as it is not instruction accurate, and does not allow
tracking the SP value as it changes.
Commit 207a6cb06990c ("ARM: 8224/1: Add unwinding support for memmove
function") addressed this by carving up the function in different chunks
as far as the unwinder is concerned, and keeping a set of unwind
directives for each of them, each corresponding with the state of the
stack pointer during execution of the chunk in question. This not only
duplicates unwind info unnecessarily, but it also complicates unwinding
the stack upon overflow.
Instead, let's do what the compiler does when the SP is updated halfway
through a function, which is to use a frame pointer and emit the
appropriate unwind directives to communicate this to the unwinder.
Note that Thumb-2 uses R7 for this, while ARM uses R11 aka FP. So let's
avoid touching R7 in the body of the function, so that Thumb-2 can use
it as the frame pointer. R11 was not modified in the first place.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Keith Packard <keithpac@amazon.com>
Tested-by: Marc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
2021-10-04 12:29:11 +03:00
|
|
|
ldmfd sp!, {r5, r6, r8 - r10}
|
2005-11-01 22:52:23 +03:00
|
|
|
|
|
|
|
14: ands ip, r2, #28
|
|
|
|
beq 16f
|
|
|
|
|
2014-02-25 11:41:09 +04:00
|
|
|
15: mov lr, r3, lspush #\push
|
2005-11-01 22:52:23 +03:00
|
|
|
ldr r3, [r1, #-4]!
|
|
|
|
subs ip, ip, #4
|
2014-02-25 11:41:09 +04:00
|
|
|
orr lr, lr, r3, lspull #\pull
|
2005-11-01 22:52:23 +03:00
|
|
|
str lr, [r0, #-4]!
|
|
|
|
bgt 15b
|
|
|
|
CALGN( cmp r2, #0 )
|
|
|
|
CALGN( bge 11b )
|
|
|
|
|
|
|
|
16: add r1, r1, #(\pull / 8)
|
|
|
|
b 8b
|
|
|
|
|
|
|
|
.endm
|
|
|
|
|
|
|
|
|
|
|
|
backward_copy_shift push=8 pull=24
|
|
|
|
|
|
|
|
17: backward_copy_shift push=16 pull=16
|
|
|
|
|
|
|
|
18: backward_copy_shift push=24 pull=8
|
|
|
|
|
ARM: memmove: use frame pointer as unwind anchor
The memmove routine is a bit unusual in the way it manages the stack
pointer: depending on the execution path through the function, the SP
assumes different values as different subsets of the register file are
preserved and restored again. This is problematic when it comes to EHABI
unwind info, as it is not instruction accurate, and does not allow
tracking the SP value as it changes.
Commit 207a6cb06990c ("ARM: 8224/1: Add unwinding support for memmove
function") addressed this by carving up the function in different chunks
as far as the unwinder is concerned, and keeping a set of unwind
directives for each of them, each corresponding with the state of the
stack pointer during execution of the chunk in question. This not only
duplicates unwind info unnecessarily, but it also complicates unwinding
the stack upon overflow.
Instead, let's do what the compiler does when the SP is updated halfway
through a function, which is to use a frame pointer and emit the
appropriate unwind directives to communicate this to the unwinder.
Note that Thumb-2 uses R7 for this, while ARM uses R11 aka FP. So let's
avoid touching R7 in the body of the function, so that Thumb-2 can use
it as the frame pointer. R11 was not modified in the first place.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Keith Packard <keithpac@amazon.com>
Tested-by: Marc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
2021-10-04 12:29:11 +03:00
|
|
|
UNWIND( .fnend )
|
2008-08-28 14:22:32 +04:00
|
|
|
ENDPROC(memmove)
|
2020-10-26 01:52:08 +03:00
|
|
|
ENDPROC(__memmove)
|