[Tinyos-devel] nesc.xml bitoffset error

[WenZhan Song]

Well, I do not agree the code is invalid - this used often in
tinyos-1.xnetworking code.  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.

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.

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/24c5aa1c/attachment.html