[Tinyos Core WG] proposal for some (small) changes in the core

[Vlado Handziski]

The mspgcc 3.2.3 is a stable branch where most of the modifications are
bug-fixes. We are not trying to follow HEAD in the sense of constantly
changing the version of gcc we are using. We just want to update the chain
to a recent release of the same stable version. There is nothing holly about
the date when the CVS snapshot has been made for the current tinyos mspgcc
tools. This date was not a result of some testing process, etc. What we are
proposing is to change this snapshot with another more recent snapshot
hoping that the latter one has more bugs fixed than the one we are using
now.

Vlado


On Tue, May 27, 2008 at 8:27 PM, Philip Levis <pal at cs.stanford.edu> wrote:

>
> On May 27, 2008, at 11:25 AM, David Gay wrote:
>
> > On Tue, May 27, 2008 at 10:36 AM, Philip Levis <pal at cs.stanford.edu>
> > wrote:
> >>
> >> On May 27, 2008, at 9:57 AM, Jan Hauer wrote:
> >>
> >>>
> >>> (*) There is problem with tos/lib/timer/VirtualizeAlarmC.nc on
> >>> msp430:
> >>> with mspgcc-3.2.3 I get a "Segmentation fault" during compilation
> >>> if I
> >>> use uint32_t as "size_type", e.g. "VirtualizeAlarmC(T32khz,
> >>> uint32_t,
> >>> uniqueCount(UQ_ALARM_32KHZ32));". The probelm is in line 135 of
> >>> VirtualizeAlarmC. Currently lines 134-136 read:
> >>>
> >>> if( m.isset[id] ) {
> >>> size_type elapsed = call AlarmFrom.getNow() - m.alarm[id].t0;
> >>> if( m.alarm[id].dt <= elapsed ) {
> >>>
> >>> I don't understand the actual cause, but when I replace this with
> >>> the
> >>> following code it compiles:
> >>>
> >>> if( m.isset[id] ) {
> >>> size_type t0 = m.alarm[id].t0;
> >>> size_type elapsed = call AlarmFrom.getNow() - t0;
> >>>  if( m.alarm[id].dt <= elapsed ) {
> >>>
> >>> This fix should not have any impacts for other platforms, so I
> >>> suggest
> >>> to use it as a workaround.
> >>
> >> These kinds of things are the reason why we settled on a version of
> >> gcc for the avr and msp430 rather than follow the head. Continually
> >> tweaking source to avoid bugs, and asking people to update their
> >> compiler often to keep up, is just not feasible.
> >
> > isn't the one he's using (3.2.3) the one we settled on for msp430,
> > though? ;-)
>
> Yes -- my point is that we can of course fix this, but imagine if
> churn on the compiler caused which lines of code cause problems to
> change regularly...
>
> Phil
> _______________________________________________
> Tinyos-2.0wg mailing list
> Tinyos-2.0wg at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-2.0wg/attachments/20080527/885d791b/attachment.htm