Date: Sun, 12 Nov 2006 19:27:21 +0300 From: Ruslan Ermilov <ru@freebsd.org> To: Joseph Koshy <joseph.koshy@gmail.com> Cc: arm@freebsd.org, Giorgos Keramidas <keramida@freebsd.org>, current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm Message-ID: <20061112162721.GD50349@rambler-co.ru> In-Reply-To: <84dead720611120758r4f1cc6e8l8ca4432ba56f3f7f@mail.gmail.com> References: <20061112142710.GE91556@wombat.fafoe.narf.at> <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> <84dead720611120758r4f1cc6e8l8ca4432ba56f3f7f@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--eheScQNz3K90DVRs
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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.
>=20
> ----- SNIP ----
> #include <stdio.h>
>=20
> struct foo {
> char x;
> };
>=20
> int
> main(int c, char **v)
> {
> printf("align=3D%d\n", __alignof__(struct foo));
> }
> ---- SNIP ---
>=20
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 ...
>=20
:-) I cheated differently;
if (sizeof(...) =3D=3D 1)
printf("1111111111111");
else if (sizeof(...) =3D=3D 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.
>=20
__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:
:=20
: struct foo { int x; char y; } foo1;
:=20
: 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.
>=20
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) =3D=3D 4.
> GCC/arm also thinks that the alignment requirement for
> `char a[1]' is `4', even though `sizeof(char a[1])`
> remains at 1.
>=20
> This doesn't make sense at many levels.
>=20
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,
--=20
Ruslan Ermilov
ru@FreeBSD.org
FreeBSD committer
--eheScQNz3K90DVRs
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)
iD8DBQFFV0tpqRfpzJluFF4RAuWPAJ9aKuu3QRgJCcPn/sii6022LKwT2QCfZWZQ
tObU0gTNX669NL3oouGWLtY=
=TZVZ
-----END PGP SIGNATURE-----
--eheScQNz3K90DVRs--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061112162721.GD50349>