From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 16:27:27 2006
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
X-Original-To: current@freebsd.org
Delivered-To: freebsd-current@FreeBSD.ORG
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 2916C16A47C;
Sun, 12 Nov 2006 16:27:27 +0000 (UTC)
(envelope-from ru@rambler-co.ru)
Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187])
by mx1.FreeBSD.org (Postfix) with ESMTP id 413E343D46;
Sun, 12 Nov 2006 16:27:19 +0000 (GMT)
(envelope-from ru@rambler-co.ru)
Received: from relay0.rambler.ru (localhost [127.0.0.1])
by relay0.rambler.ru (Postfix) with ESMTP id 1208C5FBB;
Sun, 12 Nov 2006 19:27:18 +0300 (MSK)
Received: from edoofus.park.rambler.ru (unknown [81.19.65.108])
by relay0.rambler.ru (Postfix) with ESMTP id E54295FAC;
Sun, 12 Nov 2006 19:27:17 +0300 (MSK)
Received: (from ru@localhost)
by edoofus.park.rambler.ru (8.13.8/8.13.8) id kACGRLeV051756;
Sun, 12 Nov 2006 19:27:21 +0300 (MSK) (envelope-from ru)
Date: Sun, 12 Nov 2006 19:27:21 +0300
From: Ruslan Ermilov <ru@freebsd.org>
To: Joseph Koshy <joseph.koshy@gmail.com>
Message-ID: <20061112162721.GD50349@rambler-co.ru>
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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="eheScQNz3K90DVRs"
Content-Disposition: inline
In-Reply-To: <84dead720611120758r4f1cc6e8l8ca4432ba56f3f7f@mail.gmail.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Virus-Scanned: No virus found
Cc: arm@freebsd.org, Giorgos Keramidas <keramida@freebsd.org>,
current@freebsd.org
Subject: Re: [head tinderbox] failure on arm/arm
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Nov 2006 16:27:27 -0000
--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--