On Fri, Jan 14, 2011 at 11:15:19AM -0600, Dave Martin wrote: > There's another problem which I hadn't spotted before: > > In the Thumb case, we risk violating the alignment constraints of the > code which gets copied (actually, this is also true of the ARM case, > but less likely to bite). This matters because the code may contain > literals and other data words -- quite likely given the requirement > for self-containedness. There's a solution to this - require that the thumb function is preceded by a .align 3 (which according to the GAS documentation I have means for ARM, it aligns the PC to 1 << 3 not 3 bytes.) Also require 8-byte alignment from the allocation function, and make fncpy() bug if the destination isn't 8-byte aligned. Same for the source function argument (but ignoring bit 0 of course.) We don't then have to mess with rounding allocation sizes up, nor worry about aligning the destination according to the source or any other games like that. The down-side is wastage of maybe 7 bytes a function, but that's probably going to happen anyway. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
