[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#728053: [Mesa-dev] Updated debdiff for mesa to compile on m68k



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@rutgers.edu>
#include <stdio.h>
#include <stddef.h>

struct foo {
	char c;
	int i;
};

struct bar {
	char c;
	int i __attribute__ ((aligned (8)));
};

struct baz {
	char c;
	int i __attribute__ ((aligned (2)));
};


int main(void)
{
	printf("natural: size %zu, offset c: %zu, offset i: %zu \n",
		sizeof(struct foo), offsetof(struct foo, c), offsetof(struct foo, i));
	printf("explicit 8: size %zu, offset c: %zu, offset i: %zu \n",
		sizeof(struct bar), offsetof(struct bar, c), offsetof(struct bar, i));
	printf("explicit 2: size %zu, offset c: %zu, offset i: %zu \n",
		sizeof(struct baz), offsetof(struct baz, c), offsetof(struct baz, i));
	return 0;
}

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: