Probably because the x86 still works with unaligned accesses (its
just a performance hit). The ARM processor will actually post an
exception if your program emits an unaligned access, so the
consequences of unaligned access are more dire for the ARM processor.
When faced with the dilemna of honoring a #pragma directive or
generating potentially faulty code, gcc will typically ignore the
#pragma.
Linux has a kernel option (IIRC) to emulate x86 alignment semantics
by catching the unaligned access exceptions and doing bytewise
loads/stores.
//Jesse Off
--- In "manx10004" <> wrote:
> Jesse,
>
> The __attribute__(packed) did the trick. The odd part was
> that the x86 gcc that we have been using for TS-3300 development
> did not need to have the __attibute__(packed) in order to have
> structures be of odd sizes (with the #pragma pack(1), of course)
>
> Regards
>
> --- In "Jesse Off" <> wrote:
> > This is with a struct declared with __attribute__(packed) or no?
> >
> > Keep in mind ARM needs 32 bit numbers aligned on 32bit
boundaries and
> > 16 bit numbers on 16 bit boundaries. If you use __attribute__
(packed)
> > on a structure gcc will emit 4 byte loads OR'ed and shifted into
a
> > 32bit register for 32 bit variables, which can give a
performance/code
> > size penalty. FYI.
> >
> > GCC will always pad sizeof(struct XX) to a 4 byte boundary
> > partly so you don't end up placing the struct on a non-4 byte
aligned
> > address when laying out an array. Aligning the struct on a 4-
byte
> > boundary allows gcc to emit 32-bit load/stores for accessing
members.
> > Linux may catch the alignment trap and emulate the correct
behavior if
> > you violate this, but at another large performance hit.
> >
> > //Jesse Off
> >
> > --- In "manx10004" <>
wrote:
> > > Folks,
> > >
> > > I have run into a small problem with the suggested gcc
compiler.
> > > The sizeof operator does not yield the correct size of a
structure
> > > when the structure is packed on byte bounderies. Instead the
compiler
> > > seems to give the size up to the next four byte boundery.
> > >
> > > Offsets of variables within the stucture are correct, and I
have
> > used
> > > this property to derive the proper size for the structure
which I
> > > needed for communications. Still, it is an annoyance, and took
some
> > > test code and packet sniffing to diagnose the problem.
> > >
> > > I hope this helps someone else out of a simular situation.
> > > Regards
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|