Dave Martin [off-list ref] writes:
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: Kevin Hilman <redacted>
along with Jean's OMAP patch on:
OMAP2420/n810: including basic suspend/resume test.
OMAP16xx/OSK: boot test only.
Kevin
On Wed, Jan 19, 2011 at 10:29 PM, Kevin Hilman [off-list ref] wrote:
Dave Martin [off-list ref] writes:
quoted
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: Kevin Hilman <redacted>
along with Jean's OMAP patch on:
OMAP2420/n810: including basic suspend/resume test.
OMAP16xx/OSK: boot test only.
Kevin
Thanks
---Dave
On Thu, Jan 20, 2011 at 9:42 AM, Dave Martin [off-list ref] wrote:
On Wed, Jan 19, 2011 at 10:29 PM, Kevin Hilman [off-list ref] wrote:
quoted
Dave Martin [off-list ref] writes:
quoted
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: Kevin Hilman <redacted>
along with Jean's OMAP patch on:
OMAP2420/n810: including basic suspend/resume test.
OMAP16xx/OSK: boot test only.
Kevin
Thanks
---Dave
Any more comments on this patch?
I have no further changes so far.
Cheers
---Dave
Hi Dave,
On Mon, Jan 24, 2011 at 2:50 PM, Dave Martin [off-list ref] wrote:
On Thu, Jan 20, 2011 at 9:42 AM, Dave Martin [off-list ref] wrote:
quoted
On Wed, Jan 19, 2011 at 10:29 PM, Kevin Hilman [off-list ref] wrote:
quoted
Dave Martin [off-list ref] writes:
quoted
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: Kevin Hilman <redacted>
along with Jean's OMAP patch on:
OMAP2420/n810: including basic suspend/resume test.
OMAP16xx/OSK: boot test only.
Kevin
Thanks
---Dave
Any more comments on this patch?
I have no further changes so far.
Ok to me. The changes are now in the omap-testing branch of Tony's tree [1].
[1] http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=shortlog;h=refs/heads/omap-testing
Regards,
Jean
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