On Tue, May 26, 2009 at 5:13 PM, Sven Eckelmann sven.eckelmann@gmx.de wrote:
On Tuesday 26 May 2009 20:50:56 Nathan Wharton wrote:
I added the following patch:
Please don't introduce more magic numbers. If you need an alignment on integer granularity then please use sizeof(int) instead of a simple constant. The rest looks quite good and logical. I assumed that the only architecture without automatic catching of alignment problems is mips with load operators to the fp registers (never had such problems on simple arm machine nor could I produce that problem on them). Is there any other documentation about such problems on xscale or can you proof this with an test program (malloc 6 byte, write uint32_t to first 4 byte, write another uint32_t to byte 2-5, compare bytes with input - don't forget to set it volatile)? Your current proof if concept test only shows that the "overriden" bytes will not get overriden after moving them some bytes higher.
I didn't really mean for that to be an accepted patch, just a quick test. Maybe the trailing magic number could just be a byte so you don't have to allocate more memory. I'm sure there are other things to do too.
I haven't looked at any documentation for the xscale for this problem. I can do a test program. I have seen this type of problem before, but it would throw a bus error instead of going along with an incorrect result.
========================================= #include <stdio.h> #include <stdlib.h>
#define x_moved(pos) ((int*)&x[pos])[0] static const int value1 = 0x01234567; static const int value2 = 0x89abcdef;
int main() { volatile char *x = (char*)malloc(sizeof(int) * 2); x_moved(0) = value1; x_moved(2) = value2;
if (x_moved(2) != value2) { printf("ERROR Value: "); } else { printf("Value: "); } printf("%x %x\n", x_moved(0) , x_moved(2));
free(x); return 0; } =========================================
Best regards, Sven
Thanks for your help.