Re: [head tinderbox] failure on arm/arm

On Sun, Nov 12, 2006 at 09:28:49PM +0530, Joseph Koshy wrote:
> The following program prints `1' on the AMD64, i386 and on
> sparc64.
> 
> ----- SNIP ----
> #include <stdio.h>
> 
> struct foo {
>        char x;
> };
> 
> int
> main(int c, char **v)
> {
>        printf("align=%d\n", __alignof__(struct foo));
> }
> ---- SNIP ---
> 
Yes.

> I don't have a way of running ARM binaries, but
> disassembly of the binary shows:
> 00000000 <main>:
>  ... snip ...
>  20:   e59f0010        ldr     r0, [pc, #16]   ; 38 <.text+0x38>
>  24:   e3a01004        mov     r1, #4  ; 0x4
>  28:   ebfffffe        bl      28 <main+0x28>
>  2c:   e1a00003        mov     r0, r3
>  ... snip ...
> 
:-)  I cheated differently;

	if (sizeof(...) == 1)
		printf("1111111111111");
	else if (sizeof(...) == 2)
		printf("2222222222222");

and then running strings(1) on the object file to find the
answer.

> If I am reading the assembly correctly, GCC thinks that
> the alignment for struct foo is '4'. However, changing
> the program print `__alignof__(foo.x)' results in a value
> of `1' being loaded into R1.
> 
__alignof__(foo.x) has nothing to do with __alignof__(foo);
here's a relevant snippet from gcc.info:

:  If the operand of `__alignof__' is an lvalue rather than a type, its
: value is the required alignment for its type, taking into account any
: minimum alignment specified with GCC's `__attribute__' extension (*note
: Variable Attributes::).  For example, after this declaration:
: 
:      struct foo { int x; char y; } foo1;
: 
: the value of `__alignof__ (foo1.y)' is 1, even though its actual
: alignment is probably 2 or 4, the same as `__alignof__ (int)'.

> And then `sizeof (struct foo)` appears to be 4 with GCC/arm
> and 1 on the other architectures.
> 
Yes, but even with this insane sizeof(), it should not be an
alignment problem; see my other email which shows that alignment
of a four-byte structure can still be 1 byte (like is the case
for "struct ar_hdr" on all other arches).

It was always my basic sunderstanding that an alignment of a
structure type is a maximum of alignments of its members, so
this

struct foo {
        char foo[16];
        char x;
        char bar[32];
};

doesn't have alignment requirements, and this

struct foo {
        char foo[16];
        int x;
        char bar[32];
};

should be 4 bytes aligned assuming sizeof(int) == 4.

> GCC/arm also thinks that the alignment requirement for
> `char a[1]' is `4', even though `sizeof(char a[1])`
> remains at 1.
> 
> This doesn't make sense at many levels.
> 
For one thing, such a structure is not "portable" --
you cannot pass it over a network safely without the
__attribute__((packed)) which should be redundant here.


Cheers,
-- 
Ruslan Ermilov
ru_at_FreeBSD.org
FreeBSD committer