[Tinyos-devel] nesc.xml bitoffset error

[David Gay]

On Feb 7, 2008 5:26 PM, WenZhan Song <wenzhan.song at gmail.com> wrote:
> The nx_ prefix is not supported in tinyos-1.x or maybe some environment
> thing is wrong in our machine.

It's a feature of nesC, not TinyOS. It's been present in versions of
nesC since 1.2.0. Check what nescc --version reports to find out your
version of nesC.

> 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.

As I said earlier, packed doesn't work on the msp430-based platforms
(telosb/tmote, tinynode, probably several others). If you care about
the ability to send messages between different platforms, packed will
only "work" (allow interoperability) between platforms with the same
endianness.

David Gay

>
> 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
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>