[PATCH v4] 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 <redacted>
Tested-by: Jean Pihet <redacted>
---
 arch/arm/include/asm/fncpy.h |   96 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 96 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/include/asm/fncpy.h

diff --git a/arch/arm/include/asm/fncpy.h b/arch/arm/include/asm/fncpy.h
new file mode 100644
index 0000000..8b94b5f
--- /dev/null
+++ b/arch/arm/include/asm/fncpy.h

@@ -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.
+ *
+ * NOTE: that the copied function body must be entirely self-contained and
+ * position-independent in order for this to work properly.
+ *
+ * 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.
+ *
+ * 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

On Fri, Jan 14, 2011 at 10:17 PM, Dave Martin [off-list ref] wrote:

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.

Regards,
Jean

+ *
+ * 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

Hi,

On Mon, Jan 17, 2011 at 2:02 PM, Jean Pihet [off-list ref] wrote:

[...]

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

-----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
[off-list ref] wrote:

[...]

quoted

Note that aligning the source and destination pointers to a

multiple

quoted

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

carefully

quoted

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.

I don't think there can be overflow issue considering it's current
use and available SRAM on OMAP.

How much additional memory you will need to take care of
alignment.

Max additional memory = total fns * ( 8 + 8)
			    = ~ 10 * 16
			    = 160 bytes.

Should be ok.

Regards,
Santosh

Hi Dave,

On Mon, Jan 17, 2011 at 4:35 PM, Dave Martin [off-list ref] wrote:

Hi,

On Mon, Jan 17, 2011 at 2:02 PM, Jean Pihet [off-list ref] wrote:

[...]

quoted

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.

Agree. It does not look like there are SRAM overflows today. Note that
in that case you will get warned soon enough by the 'Not enough space
in SRAM' message.
One could think about some nasty side-effects bugs like badly written
PIC code, hardcoded addresses... that appear to work with the current
version. In short this needs to be thoroughly tested on OMAP1/2/3
platforms.

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.

That is OK. I have a patch ready for OMAP1/2/3, tested on OMAP3 only.

Cheers
---Dave

Thanks,
Jean

On Mon, Jan 17, 2011 at 03:02:20PM +0100, Jean Pihet wrote:

On Fri, Jan 14, 2011 at 10:17 PM, Dave Martin [off-list ref] wrote:

quoted

+ * 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.
+ *
+ * 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.

OMAP3 is ARMv7, so is EABI.  EABI requires 64-bit data to be aligned to
natural 64-bit boundaries, so architecturally it's correct.

Nevertheless, the code may not be using 64-bit data, so that doesn't
apply - but fncpy() can't know that.

* Dave Martin [off-list ref] [110114 13:17]:

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 <redacted>
Tested-by: Jean Pihet <redacted>

Boot tested on osk5912 and n800:

Tested-by: Tony Lindgren <tony@atomide.com>

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?

Cheers
---Dave

---------- Forwarded message ----------
From: Dave Martin <redacted>
Date: Wed, Jan 26, 2011 at 11:57 AM
Subject: [PATCH v4] ARM: Thumb-2: Symbol manipulation macros for
function body copying
To: patches at arm.linux.org.uk
Cc: Dave Martin <redacted>


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 <redacted>
Tested-by: Jean Pihet <redacted>
Tested-by: Tony Lindgren <tony@atomide.com>
Tested-by: Kevin Hilman <redacted>
--
KernelVersion: 2.6.37

diff --git a/arch/arm/include/asm/fncpy.h b/arch/arm/include/asm/fncpy.h
new file mode 100644
index 0000000..8b94b5f
--- /dev/null
+++ b/arch/arm/include/asm/fncpy.h

@@ -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.
+ *
+ * NOTE: that the copied function body must be entirely self-contained and
+ * position-independent in order for this to work properly.
+ *
+ * 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.
+ *
+ * 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);
+ *
+ * ... 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

On Wed, Jan 26, 2011 at 04:05:33PM +0000, Dave Martin wrote:

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?

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.

On Wed, Jan 26, 2011 at 4:38 PM, Russell King - ARM Linux
[off-list ref] wrote:

On Wed, Jan 26, 2011 at 04:05:33PM +0000, Dave Martin wrote:

quoted

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?

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.

Darn, not enough ---

Looks like I did something stupid after all...

The patch should be successfully posted now -- apologies for the spam!

Cheers
---Dave