[Tinyos-devel] nesc.xml bitoffset error

[WenZhan Song]

The nx_ prefix is not supported in tinyos-1.x or maybe some environment
thing is wrong in our machine.

Anyway, I just want to know confirm one thing:  whether defining all
structure with attribute(packed) can avoid those byte alignment problems in
all platforms. The easier solution is better, we do not have time to dig
into those compiler or tool chain details.

WenZhan
On Feb 7, 2008 3:59 PM, David Gay <dgay42 at gmail.com> wrote:

> On Feb 7, 2008 3:29 PM, WenZhan Song <wenzhan.song at gmail.com> wrote:
> > Well, I do not agree the code is invalid - this used often in tinyos-1.x
> > networking code.
>
> And that code is broken on any platform with alignment restrictions.
> When we wrote it, we knew it was broken, but it was convenient on
> 8-bit platforms (the rene and mica motes). It also ran "ok" on x86
> because x86 supports unaligned accesses. When people wrote the first
> msp430 ports (which requires ints to have 2-byte alignment), they
> hacked the TOSMsg structure to guarantee that data was aligned to a
> multiple of 2, but this was very much a hack.
>
> We liked this style of programming so much that we invented a language
> feature (external types) to support it in a non-broken, portable
> way... (see below)
>
> > For instance, we frequently see MultihopMsg *netMsg =
> > (MultihopMsg *)msg->data; while the "data" offset in TOS_Msg is 10. We
> can
> > not assume a user pre-knows the pointer is pointing to an address
> multiple
> > of 2 but not 4.
>
> Which is why you can't do the cast to a type with alignment restrictions.
>
> > At least, we see packed attribute works fine in iMote2 according to our
> > preliminary test. Thanks for reminding gcc of MSP430 though. We will
> verify
> > that with MicaZ and TelosB later.
>
> Just use external types (nx_struct and co). They are precisely
> designed to address this issue. You just need to write:
> typedef nx_struct tTestPointer_nx
>  {
>    nx_uint8_t m;
>    nx_uint16_t k;
>    nx_uint32_t l;
>  } tTestPointer_nx;
>
> and your code will work on all platforms.
>
> David Gay
>
>
> > On Feb 7, 2008 2:41 PM, David Gay <dgay42 at gmail.com> wrote:
> >
> > >
> > > On Feb 7, 2008 11:57 AM, WenZhan Song <wenzhan.song at gmail.com> wrote:
> > > > I absolutely agree with you - somewhere is wrong.
> > >
> > > Ok, after looking at the code a little: your C code is invalid (i.e.
> > > it depends on undefined behaviour), which is why it doesn't "work".
> > > The compiler is not buggy.
> > >
> > > A little explanation: on most processors (8-bit processors and x86
> > > being exceptions...), most types have alignment restrictions - 2-byte
> > > integers must be at even addresses, 4-byte integers must be at an
> > > address that is a multiple of four, etc. If you take an arbitrary
> > > pointer, cast it to something with alignment restrictions, and then
> > > use that pointer, you will have problems (segmentation faults,
> > > mysterious behaviour, etc).
> > >
> > > Your example casts an arbitrary pointer (testMsg_nopack.data), which
> > > happens to be a multiple of 2 but not 4 in your run (5c00300a)  to a
> > > pointer to something which *must* be a multiple of 4 (on ARM, the
> > > tTestPointer_nopack structure requires a multiple of 4 because it
> > > contains a 4-byte integer). The compiler assumes when generating code
> > > that pointers to a type T respect T's alignment rules - if you break
> > > that assumption, then your code won't work, as your example
> > > illustrates...
> > >
> > > The short version: you can't take an arbitrary pointer into an array
> > > of bytes and make it to a pointer to an arbitrary type T, as this
> > > violates alignment assumptions in the C compiler.
> > >
> > > Two fixes:
> > > * gcc's packed attribute allows you to create a structure with no
> > > alignment restrictions, so arbitrary byte pointers *can* be cast to
> > > pointers to packed structures. However, packed is gcc-specific and
> > > broken on earlier gcc implementations (including the gcc version used
> > > by TinyOS for msp430 platforms). Thus packed should not be used in any
> > > portable TinyOS code (it was, alas, somewhat heavily abused in TinyOS
> > > 1.x, mostly to make life simpler when using tossim).
> > >
> > > * nesC's external types (those things starting with nx_, like
> > > nx_struct { ... }, nx_uint8_t, etc) also have no alignment
> > > restrictions. They have been available since nesC 1.2.0, so there's no
> > > reason to avoid them at this point. In TinyOS 2, they are used for all
> > > packet formats in networking code. They work for all platforms, and,
> > > unlike gcc's packed attribute, also specify endianness, so simplify
> > > writing networking code that interoperates across different platforms.
> > >
> > > David Gay
> > >
> > >
> > >
> > >
> > > > On Feb 7, 2008 11:55 AM, David Gay <dgay42 at gmail.com> wrote:
> > > >
> > > > >
> > > > > On Feb 7, 2008 11:25 AM, WenZhan Song <wenzhan.song at gmail.com>
> wrote:
> > > > > > David,
> > > > > >
> > > > > > Your suggestions can correct the XML bitoffset problem of
> non-packed
> > > > > > structure, but it does not solve the second problem:
> > > > > >
> > > >
> >
> http://sensorweb.vancouver.wsu.edu/wiki/index.php/Tips#Problem2:_If_not.2C_the_initial_values_are_even_set_to_the_wrong_addresse_in_memory
> > > > > >
> > > > > > According to our test, without "structure_size_boundary=32", it
> > works
> > > > great
> > > > > > if we always define packed structure. With it, it even has
> problems
> > with
> > > > > > "packed" structure.
> > > > >
> > > > > I'll look at the details later, but the nesC compiler has no
> influence
> > > > > on the layout of regular C structures (as opposed to nx_structs,
> which
> > > > > are layed out by nesC). If you're not getting what you expect in
> terms
> > > > > of layout from a C structure, either:
> > > > > - there's a bug in gcc
> > > > > - you're not understanding gcc's layout rules for your
> architecture
> > > > correctly
> > > > >
> > > > > David Gay
> > > > >
> > > >
> > > >
> > >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20080207/df62b856/attachment.html