[head tinderbox] failure on arm/arm
Ruslan Ermilov
ru at freebsd.org
Sun Nov 12 08:27:27 PST 2006
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20061112/89640a5a/attachment.pgp
More information about the freebsd-current
mailing list