Bug#728053: Updated debdiff for mesa to compile on m68k
On Thu, 17 Jul 2014, Eero Tamminen wrote:
> While effect of unaligned accesses is normally invisible,
No, the compiler is inserting padding here silently.
We call this “implicit padding”. The problem with it
is that this padding is architecture-dependent, and
some platforms have other alignment requirements than
other platforms.
Take this example:
struct {
char c;
int i;
} foo;
This looks like this to the programmer:
┌───┬───┬───┬───┬───┐
│ c │ i i i i │
└───┴───┴───┴───┴───┘
But it looks like this on i386:
┌───┬───┬───┬───┬───┬───┬───┬───┐
│ c │ XpaddingX │ i i i i │
└───┴───┴───┴───┴───┴───┴───┴───┘
And only like this on m68k:
┌───┬───┬───┬───┬───┬───┐
│ c │ X │ i i i i │
└───┴───┴───┴───┴───┴───┘
This is because the compiler uses the architecture’s optimal
minimum alignment for “implicit” padding, to avoid the misalignment
you’re talking about. On i386, access to a 32-bit quantity is fast
if it’s 4-byte aligned; on m68k, 2-byte alignment is not only enough
for it to be fast (4-byte would have no benefit), but is also required
by the ABI.
To fix this, we use explicit padding:
struct {
char c;
char unused1[3];
int i;
} foo;
Now all cases look the same (except if you have a CPU which
wants to align its “int”s to 64 bit…).
The problem here is that the code in question uses arrays of
such structs with implicit padding, and checks their sizes
against its expectations. Maybe because the array is written
directly to the hardware.
What my patch does is to insert e̲x̲p̲l̲i̲c̲i̲t̲ padding to exactly
match the i̲m̲p̲l̲i̲c̲i̲t̲ padding present on the i386 architecture,
to make this the “minimum amount of padding” used. (Other
architectures may still insert implicit padding, e.g. if
they want their “int”s to be 64-bit aligned, but that’s
outside of the scope of this, and will fail with that code
anyway.)
bye,
//mirabilos
--
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...
Reply to: