100 likes | 223 Views
Tool Working Group Report. John Regehr. Tool WG Agenda. Technology transfer: Move software tools from research into practical use for TinyOS 2.x developers What kind of tools? Verification / validation Optimization Debugging Etc. Current Focus: Safe TinyOS. Language-based safety on motes
E N D
Tool Working Group Report John Regehr
Tool WG Agenda • Technology transfer: Move software tools from research into practical use for TinyOS 2.x developers • What kind of tools? • Verification / validation • Optimization • Debugging • Etc.
Current Focus: Safe TinyOS • Language-based safety on motes • Pointer/array errors are trapped before they happen • No more memory corruption • Safety checks added to C code emitted by nesC compiler • Lots of details in our SenSys 07 paper
Module-Level Safety module HplAtm128Timer0AsyncP @unsafe() { … } module HplAtm128Timer0AsyncP @safe() { … } • This is an escape hatch • Unsafe means that no safety checks are inserted in the module’s code • Modules without either attribute default to unsafe
Annotations for Safety interface Packet { command void clear (message_t* SINGLE NONNULL msg); command uint8_payloadLength (message_t* SINGLE NONNULL msg); … }
New Format Annotations interface Packet { command void clear (message_t* @single() @nonnull() msg); command uint8_payloadLength (message_t* @single() @nonnull() msg); … }
Interface Annotations In nesdoc /* @param * 'message_t *@single() @nonnull()msg' is * the packet to clear */ command void clear (message_t* msg);
How to handle traps? • Reboot • Blink LEDs • Send serial packet • Custom code you write • Failure information is a small integer that a different tools turns into a nice error message
Next Steps • Now: Integrating into CVS head • Very soon: Solicit early users on –devel • Upgrade toolchain • Type “make micaz safe” • This Spring: Release as part of 2.1
Other Tools • Stack depth analysis • Working on it… • Debugger? • GUI front end? • What else do you want?