[Mesa-dev] Updated debdiff for mesa to compile on m68k

[Jan Vesely]

On Thu, 2014-07-17 at 10:21 +0200, Thorsten Glaser wrote:
> 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.)

just a question
why not use __attribute__ ((aligned(X))) for explicit padding?
the attached program produces the following output on my x64 machine:

natural: size 8, offset c: 0, offset i: 4 
explicit 8: size 16, offset c: 0, offset i: 8 
explicit 2: size 8, offset c: 0, offset i: 4

and I get the same output on arm32.

regards,
Jan

> 
> bye,
> //mirabilos

-- 
Jan Vesely <jan.vesely at rutgers.edu>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: align.c
Type: text/x-csrc
Size: 675 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140717/5bf192e8/attachment-0001.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140717/5bf192e8/attachment-0001.sig>