|
From: Julian S. <js...@ac...> - 2015-01-19 10:47:33
|
On 19/01/15 10:45, Florian Krohm wrote: > On 19.01.2015 05:00, John Reiser wrote: >> The code in LibVEX_Alloc works "by accident". The result happens to be correct >> for current architectures (x86, x86_64, PowerPC, PowerPC-64, MIPS, MIPS-64, ARM, >> ARM-64) and compilers (gcc, icc, clang, xlc, ...) However, an adversarial compiler >> could force LibVEX_Alloc to return a value which is not properly aligned. >> In particular, PowerPC-64 is on the cusp. Also, LibVEX_Alloc wastes space. The current code produces an alignment of 8 I think, which is wrong on all -- or, at least, almost all -- targets anyway. Even on x86 the minimum correct alignment is 16, for storage of vector registers (xmm). But LibVEX_Alloc is designed to support vex, and be a very fast and compact bump-allocator. Vex doesn't do any vector loads/stores so an alignment of 8 seems OK. Given that vex allocates at least at hundreds of megabytes per second and given that D1$ space is very limited, especially on lower-end targets, I'd prefer not to change the alignment requirement to 16 unless really necessary. Maybe a simple solution would be to remove from LibVEX_Alloc the "struct align" thing and hardwire 8 as the alignment. And also, in LibVEX_Init, put some assertions to check that 8 is in fact OK for the set of types we're interested in. Given that the base pointer for the area is already 8 aligned, I don't then see how aligning the size rather than the pointer could lead to misaligned results. Aligning the size rather than the pointer has the advantage that it can be done by gcc's constant folding at compile time, for any allocation of constant size, which almost all of them are. As for LibVEX_Alloc(0), that should never happen. I guess we could add an assert in there on the assumption that it will get constant folded out for all constant-size allocation requests. J |