ARM: Thumb-2: Symbol manipulation macros for function body copying

In low-level board support code, there is sometimes a need to copy a function body to another location at run-time.

A straightforward call to memcpy doesn't work in Thumb-2, because bit 0 of external Thumb function symbols is set to 1, indicating that the function is Thumb. ?Without corrective measures, this will cause an off-by-one copy, and the copy may be called using the wrong instruction set.

This patch adds an fncpy() macro to help with such copies.

Particular care is needed, because C doesn't guarantee any defined behaviour when casting a function pointer to any other type. ?This has been observed to lead to strange optimisation side-effects when doing the arithmetic which is required in order to copy/move function bodies correctly in Thumb-2.

Thanks to Russell King and Nicolas Pitre for their input on this patch.

Signed-off-by Dave Martin <[email protected]>

Tested-by Jean Pihet <[email protected]>

---
?arch/arm/include/asm/fncpy.h | ? 96 ++++++++++++++++++++++++++++++++++++++++++ ?1 files changed, 96 insertions(+), 0 deletions(-)
?create mode 100644 arch/arm/include/asm/fncpy.h

arch/arm/include/asm/fncpy.h new file +26 -0

new file mode 100644
index 0000000..8b94b5f
@@ -0,0 +1,96 @@
+/*
+ * arch/arm/include/asm/fncpy.h - helper macros for function body copying
+ *
+ * Copyright (C) 2011 Linaro Limited
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ?See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+/*
+ * These macros are intended for use when there is a need to copy a low-level
+ * function body into special memory.
+ *
+ * For example, when reconfiguring the SDRAM controller, the code doing the
+ * reconfiguration may need to run from SRAM.
+ *

arch/arm/include/asm/fncpy.h new file +60 -1

+ *
+ * Typical usage example:
+ *
+ * extern int f(args);
+ * extern uint32_t size_of_f;
+ * int (*copied_f)(args);
+ * void *sram_buffer;
+ *
+ * copied_f = fncpy(sram_buffer, &f, size_of_f);
+ *
+ * ... do any required D-side/I-side synchronisation ...
+ *
+ * ... later, call the function: ...
+ *
+ * copied_f(args);
+ *
+ * The size of the function to be copied can't be determined from C:
+ * this must be determined by other means, such as adding assmbler directives
+ * in the file where f is defined.
+ */
+
+#ifndef __ASM_FNCPY_H
+#define __ASM_FNCPY_H
+
+#include <linux/types.h>
+#include <linux/string.h>
+
+#include <asm/bug.h>
+#include <asm/cacheflush.h>
+
+/*
+ * Minimum alignment requirement for the source and destination addresses
+ * for function copying.
+ */
+#define FNCPY_ALIGN 8
+
+#define fncpy(dest_buf, funcp, size) ({ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
+ ? ? ? uintptr_t __funcp_address; ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
+ ? ? ? typeof(funcp) __result; ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
+ ? ? ? asm("" : "=r" (__funcp_address) : "0" (funcp)); ? ? ? ? ? ? ? ? \
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
+ ? ? ? /* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
+ ? ? ? ?* Ensure alignment of source and destination addresses, ? ? ? ?\
+ ? ? ? ?* disregarding the function's Thumb bit: ? ? ? ? ? ? ? ? ? ? ? \
+ ? ? ? ?*/ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
+ ? ? ? BUG_ON((uintptr_t)(dest_buf) & (FNCPY_ALIGN - 1) || ? ? ? ? ? ? \
+ ? ? ? ? ? ? ? (__funcp_address & ~(uintptr_t)1 & (FNCPY_ALIGN - 1))); \
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
+ ? ? ? memcpy(dest_buf, (void const *)(__funcp_address & ~1), size); ? \
+ ? ? ? flush_icache_range((unsigned long)(dest_buf), ? ? ? ? ? ? ? ? ? \
+ ? ? ? ? ? ? ? (unsigned long)(dest_buf) + (size)); ? ? ? ? ? ? ? ? ? ?\
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
+ ? ? ? asm("" : "=r" (__result) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
+ ? ? ? ? ? ? ? : "0" ((uintptr_t)(dest_buf) | (__funcp_address & 1))); \
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
+ ? ? ? __result; ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
+})
+
+#endif /* !__ASM_FNCPY_H */
--

1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo at vger.kernel.org
More majordomo info at ?http://vger.kernel.org/majordomo-info.html

Note that aligning the source and destination pointers to a multiple of 8 bytes has an impact on the behavio(u)r and so must be carefully thought and tested on OMAP1/2/3 platforms.

-----Original Message-----
From: linux-omap-owner at vger.kernel.org [mailto:linux-omap- owner at vger.kernel.org] On Behalf Of Dave Martin
Sent: Monday, January 17, 2011 9:06 PM
To: Jean Pihet
Cc: linux-arm-kernel at lists.infradead.org; linux-
omap at vger.kernel.org; Jean Pihet
Subject: Re: [PATCH v4] ARM: Thumb-2: Symbol manipulation macros for function body copying

Hi,

On Mon, Jan 17, 2011 at 2:02 PM, Jean Pihet
<[email protected]> wrote:

[...]

Quoted 1 line

Note that aligning the source and destination pointers to a

multiple

Quoted 1 line

of 8 bytes has an impact on the behavio(u)r and so must be

carefully

Quoted 1 line

thought and tested on OMAP1/2/3 platforms.

Do you have any specific concerns regarding this?

Currently, the only issue I can think of is that the need to allocate
aligned memory from the SRAM will increase the total amount allocated,
which could be a problem if we end up overflowing the available SRAM.

This does not appear to happen in the case I've tested -- I currently
round up the amount allocated in omap_sram_push to be a multiple of 8
bytes. This, combined with a couple of ".align 3" directives, is enough to get me a booting system on omap3... but I haven't tested exhaustively.

Hi,

On Mon, Jan 17, 2011 at 2:02 PM, Jean Pihet <[email protected]> wrote:

[...]

Quoted 3 lines

Note that aligning the source and destination pointers to a multiple of 8 bytes has an impact on the behavio(u)r and so must be carefully thought and tested on OMAP1/2/3 platforms.

Do you have any specific concerns regarding this?

Currently, the only issue I can think of is that the need to allocate aligned memory from the SRAM will increase the total amount allocated, which could be a problem if we end up overflowing the available SRAM.

This does not appear to happen in the case I've tested -- I currently round up the amount allocated in omap_sram_push to be a multiple of 8 bytes. ?This, combined with a couple of ".align 3" directives, is enough to get me a booting system on omap3... but I haven't tested exhaustively.

Cheers
---Dave

Quoted 8 lines · Dave Martin

+ * These macros are intended for use when there is a need to copy a low-level
+ * function body into special memory.
+ *
+ * For example, when reconfiguring the SDRAM controller, the code doing the
+ * reconfiguration may need to run from SRAM.
+ *
+ * NOTE: that the copied function body must be entirely self-contained and
+ * position-independent in order for this to work properly.

Quoted 8 lines

+ *
+ * NOTE: in order for embedded literals and data to get referenced correctly,
+ * the alignment of functions must be preserved when copying. ?To ensure this,
+ * the source and destination addresses for fncpy() must be aligned to a
+ * multiple of 8 bytes: you will be get a BUG() if this condition is not met.
+ * You will typically need a ".align 3" directive in the assembler where the
+ * function to be copied is defined, and ensure that your allocator for the
+ * destination buffer returns 8-byte-aligned pointers.

Note that aligning the source and destination pointers to a multiple of 8 bytes has an impact on the behavio(u)r and so must be carefully thought and tested on OMAP1/2/3 platforms.

Hi Russell,

I tried to send this patch to your patch system, but I've received no response or any bounce. On my end the mail appears to have been sent, and previous submissions made via the same route have succeeded.

The patch doesn't seem to be in the patch system, but I'm not sure what went wrong ... hopefully I'm not doing anything stupid.

Do you have any ideas what might have gone wrong?

Quoted 9 lines · Dave Martin

Hi Russell,

I tried to send this patch to your patch system, but I've received no response or any bounce. ?On my end the mail appears to have been sent, and previous submissions made via the same route have succeeded.

The patch doesn't seem to be in the patch system, but I'm not sure what went wrong ... hopefully I'm not doing anything stupid.

Quoted 1 line

Do you have any ideas what might have gone wrong?

Probably the lack of a line matching '^PATCH\s+FOLLOWS\s*$', '^--[- ]$'.

It's rather particular about that before it'll even consider sending a reply, It's a measure to prevent excessive collateral spam and my MTA being blacklisted as a result.

In low-level board support code, there is sometimes a need to copy a function body to another location at run-time.

A straightforward call to memcpy doesn't work in Thumb-2, because bit 0 of external Thumb function symbols is set to 1, indicating that the function is Thumb. Without corrective measures, this will cause an off-by-one copy, and the copy may be called using the wrong instruction set.

This patch adds an fncpy() macro to help with such copies.

Particular care is needed, because C doesn't guarantee any defined behaviour when casting a function pointer to any other type. This has been observed to lead to strange optimisation side-effects when doing the arithmetic which is required in order to copy/move function bodies correctly in Thumb-2.

Thanks to Russell King and Nicolas Pitre for their input on this patch.

Signed-off-by Dave Martin <[email protected]>

Tested-by Jean Pihet <[email protected]>

In low-level board support code, there is sometimes a need to copy a function body to another location at run-time.

A straightforward call to memcpy doesn't work in Thumb-2, because bit 0 of external Thumb function symbols is set to 1, indicating that the function is Thumb. Without corrective measures, this will cause an off-by-one copy, and the copy may be called using the wrong instruction set.

This patch adds an fncpy() macro to help with such copies.

Particular care is needed, because C doesn't guarantee any defined behaviour when casting a function pointer to any other type. This has been observed to lead to strange optimisation side-effects when doing the arithmetic which is required in order to copy/move function bodies correctly in Thumb-2.

Thanks to Russell King and Nicolas Pitre for their input on this patch.

Signed-off-by Dave Martin <[email protected]>

Tested-by Jean Pihet <[email protected]>

Quoted 17 lines · Dave Martin

In low-level board support code, there is sometimes a need to copy a function body to another location at run-time.

A straightforward call to memcpy doesn't work in Thumb-2, because bit 0 of external Thumb function symbols is set to 1, indicating that the function is Thumb. ?Without corrective measures, this will cause an off-by-one copy, and the copy may be called using the wrong instruction set.

This patch adds an fncpy() macro to help with such copies.

Particular care is needed, because C doesn't guarantee any defined behaviour when casting a function pointer to any other type. ?This has been observed to lead to strange optimisation side-effects when doing the arithmetic which is required in order to copy/move function bodies correctly in Thumb-2.

Quoted 5 lines

Thanks to Russell King and Nicolas Pitre for their input on this patch.

Signed-off-by Dave Martin <[email protected]>

Tested-by Jean Pihet <[email protected]>

Tested-by Kevin Hilman <[email protected]>

along with Jean's OMAP patch on:

OMAP2420/n810: including basic suspend/resume test.

OMAP16xx/OSK: boot test only.

Kevin

Quoted 31 lines · Kevin Hilman

Quoted 17 lines · Dave Martin

In low-level board support code, there is sometimes a need to copy a function body to another location at run-time.

A straightforward call to memcpy doesn't work in Thumb-2, because bit 0 of external Thumb function symbols is set to 1, indicating that the function is Thumb. ?Without corrective measures, this will cause an off-by-one copy, and the copy may be called using the wrong instruction set.

This patch adds an fncpy() macro to help with such copies.

Particular care is needed, because C doesn't guarantee any defined behaviour when casting a function pointer to any other type. ?This has been observed to lead to strange optimisation side-effects when doing the arithmetic which is required in order to copy/move function bodies correctly in Thumb-2.

Quoted 5 lines

Thanks to Russell King and Nicolas Pitre for their input on this patch.

Signed-off-by Dave Martin <[email protected]>

Tested-by Jean Pihet <[email protected]>

Tested-by Kevin Hilman <[email protected]>

along with Jean's OMAP patch on:

OMAP2420/n810: including basic suspend/resume test.

Quoted 4 lines

OMAP16xx/OSK: boot test only.

Kevin

Thanks
---Dave

Quoted 37 lines · Dave Martin

Quoted 35 lines · Kevin Hilman

Quoted 17 lines · Dave Martin

In low-level board support code, there is sometimes a need to copy a function body to another location at run-time.

A straightforward call to memcpy doesn't work in Thumb-2, because bit 0 of external Thumb function symbols is set to 1, indicating that the function is Thumb. ?Without corrective measures, this will cause an off-by-one copy, and the copy may be called using the wrong instruction set.

This patch adds an fncpy() macro to help with such copies.

Particular care is needed, because C doesn't guarantee any defined behaviour when casting a function pointer to any other type. ?This has been observed to lead to strange optimisation side-effects when doing the arithmetic which is required in order to copy/move function bodies correctly in Thumb-2.

Quoted 5 lines

Thanks to Russell King and Nicolas Pitre for their input on this patch.

Signed-off-by Dave Martin <[email protected]>

Tested-by Jean Pihet <[email protected]>

Tested-by Kevin Hilman <[email protected]>

along with Jean's OMAP patch on:

OMAP2420/n810: including basic suspend/resume test.

OMAP16xx/OSK: boot test only.

Kevin

Quoted 3 lines

Thanks
---Dave

Any more comments on this patch?

I have no further changes so far.

Cheers
---Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo at vger.kernel.org
More majordomo info at ?http://vger.kernel.org/majordomo-info.html