[Tinyos-devel] nesc.xml bitoffset error

[David Gay]

On Feb 6, 2008 2:45 PM, WenZhan Song <wenzhan.song at gmail.com> wrote:
> Looks like if we use packed attribute, then the problem does not exist. But
> here is the problem we have seen:
> http://sensorweb.vancouver.wsu.edu/wiki/index.php/Tips#Always_define_a_struct_with___attribute__.28.28packed.29.29_in_nesC

That page is wrong. nesC uses a machine specification to specify the
struct (and other type) layout rules. But:
- the machine specifications are sometimes wrong (hence this thread)
- sometimes, the machine specification needs extending to properly
support a particular target (if you happened to go and see how gcc
supports different target architectures, you would understand why
getting all the necessary flexibility in place on day one was
impractical...)

> By the way, since you mentioned .platform file, the default one in CVS even
> does not work, we have to comment out "gcc=xscale-elf-gcc" to compile - is
> this right?

The machine spec (as of nesC 1.2) no longer contains the gcc compiler
name (it's redundant with the -fnesc-gcc= option). This does bring up
the issue that the "env" target does tend to be fairly nesC-release
specific, which is not ideal (two ways around this for an env-based
platform: specify the supported nesC releases and/or check the nescc
version and adjust the settings).

David Gay

> Like this:
>
> @opts = ("-fnesc-target=env",
>          "-gcc=xscale-elf-gcc",
>   "-nostartfiles",
>   "-T$TOSDIR/platform/imote2/bare.x",
>   "-fnesc-no-debug",
>   "-DTINY_OS",
>  #  "-I$TOSDIR/lib/CC2420Radio",
>   "-I$TOSDIR/platform/pxa27x/lib");
> push @opts, "-mingw-gcc" if $cygwin;
>
> # $ENV{NESC_MACHINE} = "pointer=4,4 float=4,4 double=8,4 long_double=8,4
> short=2,2 int=4,4 long=4,4 long_long=8,4 int1248_align=1,2,4,4
> wchar_size_size=4,4 char_wchar_signed=false,true gcc=xscale-elf-gcc";
>
>
> $ENV{NESC_MACHINE} = "pointer=4,4 float=4,4 double=8,4 long_double=8,4
> short=2,2 int=4,4 long=4,4 long_long=8,4 int1248_align=1,2,4,4
> wchar_size_size=4,4 char_wchar_signed=false,true";
>
> @commonplatforms = ("pxa27x");
>
>
>
>
>
>
> On Feb 6, 2008 2:20 PM, David Gay <dgay42 at gmail.com> wrote:
>
> >
> > On Feb 6, 2008 2:04 PM, Adler, Robert P <robert.p.adler at intel.com> wrote:
> > > Would this issue affect code generation in any way or only documentation
> > > creation?  Also, is structure_size_boundary a relatively new
> > > option/field, or has it been around for a while?  Finally, would the
> > > change be backwards compatible with older versions of ncc??
> >
> > It showed up in v1.2.6 (it's alluded to in nesC's notes for that
> > release). The env target doesn't like options it doesn't know, so
> > specifying it for earlier releases would be a bad idea. It affects:
> > - mig (as it needs to know structure layout)
> > - XML structure layout output
> > - constant folding (but it's unlikely to have an actual effect, except
> > if you use an offsetof/sizeof result affected by this rule as a
> > generic component argument)
> >
> > David Gay
> >
>
>