Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 12 Nov 2006 12:21:50 -0800
From:      Sam Leffler <sam@errno.com>
To:        Ruslan Ermilov <ru@freebsd.org>
Cc:        arm@freebsd.org, current@freebsd.org, Giorgos Keramidas <keramida@freebsd.org>
Subject:   Re: [head tinderbox] failure on arm/arm
Message-ID:  <4557825E.3070009@errno.com>
In-Reply-To: <20061112192810.GC1173@rambler-co.ru>
References:  <20061112133929.9194773068@freebsd-current.sentex.ca>	<20061112140010.GA47660@rambler-co.ru>	<20061112144230.GC2331@kobe.laptop>	<20061112145151.GC49703@rambler-co.ru>	<20061112151150.GA2988@kobe.laptop>	<20061112155723.GB50349@rambler-co.ru>	<20061112165904.GP6501@plum.flirble.org>	<20061112171436.GF50349@rambler-co.ru>	<20061112180758.GD4237@kobe.laptop>	<20061112132105.6bac38d6@kan.dnsalias.net> <20061112192810.GC1173@rambler-co.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
Ruslan Ermilov wrote:
> On Sun, Nov 12, 2006 at 01:21:05PM -0500, Alexander Kabaev wrote:
>> GCC expects 4-byte aligned structured on ARM but does not necessarily
>> have to. We can change the default at the expense of possible more
>> inefficient code generated and lost binary compatibility with other ARM
>> OSes out there. So this is trade off between unclear performance
>> penalty and an unspecified but certainly sizable number of other
>> landmines like this lurking on the code.
>>
>> We should decide what evil we regard as lesser.
>>
> This is the only buildworld problem so far on FreeBSD/ARM, so my
> feeling is that we can actually benefit from leaving it "as is",
> as it has a potential of making our code more portable.  Of course
> if binary compatibility for structs across platforms is an issue,
> a structure should be "packed", because otherwise the C standard
> says that "Each non-bit-field member of a structure or union object
> is aligned in an implementation-defined manner appropriate to its
> type."
> 
> On the other hand, having GCC align "struct foo { char x[11]; }"
> on a four-byte boundary (other than for backward compatibility)
> doesn't make too much sense to me.
> 
> I don't know GCC rules for alignment of structure members.  For
> example, if it's guaranteed (in GCC) that offsetof(struct foo, bar)
> is always 1 for "struct foo { char foo; char bar; }" (without the
> "packed" attribute) on all platforms and OSes GCC supports?
> I'd expect the latter to be "4" for FreeBSD/ARM but fortunately
> it stays "1", i.e., only the structure alignment is affected,
> and not of structure members (which is POLA but makes the 4 byte
> for structure alignment questionable).

This issue appears to have broken if_bridge.  On my avila board I align
rx packets to be aligned s.t. the ip header lands on a 32-bit boundary.
 This results in the ethernet header being 2-byte aligned which is ok on
other platforms.  But the compiler takes this code in bridge_forward:

        /*
         * If the interface is learning, and the source
         * address is valid and not multicast, record
         * the address.
         */
        if ((bif->bif_flags & IFBIF_LEARNING) != 0 &&
            ETHER_IS_MULTICAST(eh->ether_shost) == 0 &&
            (eh->ether_shost[0] == 0 &&
             eh->ether_shost[1] == 0 &&
             eh->ether_shost[2] == 0 &&
             eh->ether_shost[3] == 0 &&
             eh->ether_shost[4] == 0 &&
             eh->ether_shost[5] == 0) == 0) {
                (void) bridge_rtupdate(sc, eh->ether_shost,
                    src_if, 0, IFBAF_DYNAMIC);
        }

and converts the 6 byte compares to a 32-bit and 16-bit compare.  Since
the data is only 16-bit aligned the 32-bit load faults.

So the point is that just because things compile doesn't necessarily
mean they work.  And worse code that works on many/most other
architectures may not work.

	Sam



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4557825E.3070009>