Cyclone: Blog

GCC 4

Thanks to Greg, Cyclone now works with GCC 4.

You’ll need to use the latest Cyclone from SVN; instructions are at Download.

20 June 2006 by trevor #

Minix

Attention: Cyclone (latest SVN) runs out of the box on Minix!

That is all.

5 June 2006 by trevor #

Cross-compiling for the Nokia 770

The Nokia 770 has limited processing power: a 220MHz ARM-based CPU, 64MB RAM, and 128MB of non-volative storage (flash). Using the Cyclone compiler on such a limited system would be painful, maybe impossible. Instead we’ll use a special Cyclone compiler on a more powerful machine, and compile the programs there before transferring them to the 770 to run. The process is about the same regardless of whether you want to compile for the 770, the Nintendo DS, the iPod, or even more limited platforms.

The hardest part of this is getting a cross-compiling gcc. Fortunately, Nokia is using standard open source tools for their development environment, and binary distributions and good documentation are easily available.

Installing the cross-compiler

The basic development environment is Scratchbox. Scratchbox is a set of cross-compilers and emulators that let you simulate working on one processor architecture, while in fact running on a completely different architecture. In our case, we’ll be able to compile and execute ARM code while running on an x86 machine.

You can install Scratchbox and Maemo (the Nokia-specific devkit) using these instructions. Due to our particular needs, we’ll use a different set of packages than those mentioned in those instructions. Here’s the complete list of tarballs that I used:

scratchbox-core-1.0.4-i386.tar.gz
scratchbox-libs-1.0.3-i386.tar.gz
scratchbox-toolchain-arm-gcc3.4-glibc2.3-1.0.2-i386.tar.gz
scratchbox-toolchain-host-gcc-1.0.5-i386.tar.gz

The tarballs are available here. I didn’t bother to install any Scratchbox devkits, or the Maemo SDK, as these aren’t necessary to cross compile simple command-line applications.

After following the instructions you should have a working Scratchbox with ARM target. This means that when you are logged in to the Scratchbox in the ARM target, you are running ARM binaries via emulation. We also need a HOST target, where you can run x86 binaries natively. The setup for HOST is about the same as for ARM:

Using sb-menu, choose “Setup” to create the HOST target.

Name the target HOST

Select host-gcc compiler

Select debian and perl devkits

Select “none” for CPU transparency method

Select “no” for installing files

Select “yes” for selecting the target

Exit sb-menu.

You should now be running inside the HOST target in Scratchbox.

Installing Cyclone

Now, on to Cyclone. Download the distribution; you’ll need to use the SVN version to be sure it works with Maemo. Place the distribution in your Scratchbox home directory and cd to the toplevel directory. Configure and build:

./configure --target=arm-maemo-elf
make
make install

Now, create the canonical first program:

cat > hello.cyc <<ZZZ
#include <stdio.h>
int main () { printf("Hello, world!\n"); return 0; }
ZZZ

Compile it with

cyclone hello.cyc -nogc -b arm-maemo-elf

Transfer the resulting a.out to your 770. On most Linux systems you can simply plug in the 770 over USB and drag the file over; this will put the program on the memory card. Be sure to move the program off of the memory card to your home directory, because it won’t run from the memory card.

Finally, run it from an xterm:

Hello world on a 770

Under the covers

A couple of details. When you did

./configure --target=arm-maemo-elf

you set Cyclone up so that both a native (x86) compiler and a cross (ARM) compiler would be built. Because Cyclone uses gcc and associated tools as its back end, the difference between the two is just that the ARM version invokes a cross gcc toolchain instead of the native toolchain. If you examine the generated Makefile.inc, you’ll see these lines:

TARGET_CC=/scratchbox/compilers/arm-linux-gcc3.4.cs-glibc2.3/bin/arm-linux-gcc
TARGET_CFLAGS=
TARGET_RANLIB=/scratchbox/compilers/arm-linux-gcc3.4.cs-glibc2.3/bin/arm-linux-ranlib
TARGET_AR=/scratchbox/compilers/arm-linux-gcc3.4.cs-glibc2.3/bin/arm-linux-ar

If you are cross-compiling for a different architecture, or you have gotten a different version of the Scratchbox toolchains, you will need to adjust these variables.

A second detail: note that when we compiled hello.cyc, we used the -nogc flag. This means that the garbage collector will not be linked in. In fact, the normal build process will not cross-compile the garbage collector at all, so the compile will fail if you do not use -nogc.

It is possible to cross-compile the garbage collector, but I don’t have much experience with it. If you are using Scratchbox, then you can compile the garbage collector in the ARM target, and hello.cyc will run on the 770 with the garbage collector linked in. It does not run in the ARM target itself, though.

To cross-compile the garbage collector in the ARM target, do this:

cd gc
./configure --enable-threads=no --enable-shared=no --enable-cplusplus=no
make
mv .libs/libgc.a /usr/local/lib/cyclone/cyc-lib/arm-maemo-elf/gc.a

Now you should be able to compile programs to use the garbage collector as usual, by leaving off the -nogc flag.

15 May 2006 by trevor #

Write once run anywhere

Shocking news: write once run anywhere is a mirage.

… Motorola is seeking development of a broader mobile and software ecosystem for Java, with the goal of yielding “write-once, run everywhere” implementation capabilities.

… Currently, a handset maker licenses a JSR from another company and then makes changes to the reference implementation to make it work on their phone. This is done over and over again, resulting in platform variations, according to Motorola.

Or, as Carmack said last year,

Write-once-run-anywhere. Ha. Hahahahaha. We are only testing on four platforms right now, and not a single pair has the exact same quirks. All the commercial games are tweaked and compiled individually for each (often 100+) platform.

Anyway, let’s be honest: “write once run anywhere” should more accurately be, “write once run anywhere that C already runs, taking care of any portability issues.” It’s a nice goal, but the portability problem at the core has not gone away. We still need a technology to solve the portability problem, securely and reliably, and Java does not address this at all.

15 May 2006 by trevor #

Nokia 770

Since the release of Cyclone 1.0 last week, we’ve heard from a number of people interested in using Cyclone to program embedded systems. It’s actually pretty easy to set up, so I thought I’d make a couple of posts to document my experiences in cross-compiling programs for the Nokia 770 Internet Tablet. Here’s the first.

For those not familiar with the Nokia 770, it’s a computer with a four-inch touchscreen, Bluetooth, and wifi. It’s very handy to keep around in case you need to browse the web for a moment, to look up a fact or news story, or just to pass the time.

The Nokia 770

A surprising number of people think the 770 is a flop; the Washington Post says “It Does Very Little, and Not Very Well,” and CNET puts it on the list of the “Worst tech of 2006 (so far).” My judgment is the opposite: I’ve had a 770 since December and I still use it every day, quite a contrast with the pile of old Palms and Pocket PCs gathering dust in my closet.

The 770 has two killer features. First, the screen is beautiful: 800x480 resolution in 4 diagonal inches, or about 225 dpi. That’s about 4 times sharper than a standard laptop screen, and a width of 800 pixels means that most web sites can be viewed without horizontal scrolling. Once you experience browsing on the 770, you won’t bother with a smartphone or low-res Palm or Pocket PC again.

Second, Nokia is using an open source development model. The 770 runs Linux (a 2.6 kernel), the GUI is based on GTK, the compiler is gcc, the development environment is scratchbox, and all of the tools and documentation can be downloaded freely, without registration. I’ve gotten Cyclone compiling for the Nintendo DS and the iPod, but developing for those platforms isn’t much fun, because you have to work so hard to get basics like networking going. Consequently, Nokia has attracted many more developers and software ports than these other platforms, even though they were released months or years ahead of the 770.

In my next post, I’ll give the details on setting up Cyclone to compile for the 770.

14 May 2006 by trevor #

Signal handling bug in Sendmail

Here’s an interesting vulnerability:

Sendmail contains a signal race vulnerability when receiving and processing mail data from remote clients. Sendmail utilizes a signal handler for dealing with timeouts that is not async-safe and interruption of certain functions by this signal handler will cause static data elements to be left in an inconsistent state. These data elements can be used to write data to invalid parts of the stack (or heap in some scenarios), thus taking control of the vulnerable process.

It’s a good reminder that signal handling turns any program into a multithreaded program.

14 May 2006 by trevor #

Garbage collection for Cocoa

Ars Technica discusses the possibilities for Apple using garbage collection for Cocoa, their Objective-C development libraries.

Of course, it’s been possible to use garbage collection with Objective-C for a long time, using the Boehm-Demers-Weiser garbage collector that we use in Cyclone. The real question is whether Apple will use garbage collection to replace reference counting in their own applications. Ars Technica points out signs that garbage collection will at least be officially supported in the next version of the operating system, 10.5 (Leopard).

7 May 2006 by trevor #

OLPC

The One Laptop Per Child (OLPC) project has some interesting constraints. The plan is to distribute millions of laptops to the developing world, where power and connectivity will be intermittent. The laptops themselves will have to be inexpensive, so they will have limited CPU, RAM, and storage (flash only, no disk drive), much less than what you typically find on a laptop in the US.

This would be a nice platform for Cyclone: besides being resource-constrained, OLPC will need robust software, since it will be difficult to update. Cyclone’s safety combined with ability to control the memory footprint would be a win on both counts.

After considering Java (and rejecting it in part because it is not an open platform), the project has settled on Python as the basic development platform. Python has a reputation for speed, but it would be interesting to see how it compares to Cyclone in speed and memory footprint. On the small benchmarks of The Computer Language Shootout, C (compiled with gcc) seems to be something like 15 times faster and less memory hungry than Python. Assuming that Cyclone (without garbage collection) is close to C, there is still a good case to be made for Cyclone.

Safety

It’s usually a good idea to avoid programming language flames, but this one from last year is a bit amusing. It defines “freedom languages” (Ruby, Python, Perl, Smalltalk) and “safety languages” (C++, Java, C#, VB, Delphi, Haskell, Nice). At the end of the piece the author treats us to this astonishing revelation:

All other things being equal, I think I’ll choose freedom

Furthermore, “freedom” = boxers, “safety” = tighty whities (ok, not really).

The useful bit of information is that the author includes C++ on his list of “safety” languages. This points up a bit of a problem for Cyclone: there’s no accepted definition of “safety,” and, in fact, people use the word to describe unsafe languages.

I don’t think there’s a good fix for this; if I recall, Matthias Felleisen took a stab at a general definition of language safety, but I don’t know that it went anywhere, and I’m not aware of other work on the topic. And in the end, the general public will use the word as they want to, not the way we want them to.

I think that the best we can do is try to give examples of what we consider safe and unsafe. We should build a wiki page to collect this information. In the meantime, here’s one (perhaps) surprising example:

Q: if a program segfaults, is it safe?

My answer is, yes, that may be safe.

For example, imagine that you could magically transform every C program in the world so that in case of a buffer overflow, the program would immediately segfault. This would be great! It would mean that instead of being corrupted, programs would halt immediately if they were attacked. In other words, the system would have a fail-stop property.

Fail-stop would mean the difference between a corrupted, “zombie” program under the remote control of some attacker, and a dead program. Not ideal, but a great improvement. In fact, fail-stop is a crucial ingredient of one definition of safety.

The same argument can be applied in other cases. For example, there is no safety reason to check for NULL pointers, because a NULL pointer dereference on modern machines will cause a segfault. There may be other reasons (recovery from errors), but it isn’t a safety issue.

24 April 2006 by trevor #

Language popularity

Tim O’Reilly posts statistics on the technical book market. This installment contains the interesting prediction that C# will replace Java as the most popular language shortly, and may have done so already:

Microsoft languages (VB and C#) are both showing strong growth, while Java is weakening, continuing a years-long trend.

Also:

“.Net languages” refers to books that cover both C# and VB in the same book. If you give C# credit for all the books in this group, C# now just edges out Java as the most popular computer programming language. And if current growth trends continue, with Java off 6% and C# up 68%, C# will significantly extend its lead next quarter.

22 April 2006 by trevor #

Firefox security holes

There’s a new version of Firefox out (1.5.0.2), with fixes for 22 security issues, according to Secunia. My favorite is this one:

2) An error in the garbage collection in the JavaScript engine can be exploited to cause a memory corruption.

Successful exploitation may allow execution of arbitrary code.

Apparently garbage collectors are not perfect! Who knew.

Among the 22 issues there are a bunch that would clearly be prevented by a safe language like Cyclone:

3) A boundary error in the CSS border rendering implementation may be exploited to write past the end of an array.

4) An integer overflow in the handling of overly long regular expressions in JavaScript may be exploited to execute arbitrary JavaScript bytecode.

6) An error in the “InstallTrigger.install()” method can be exploited to cause a memory corruption.

13) An error in the processing of a certain sequence of HTML tags can be exploited to cause a memory corruption.

Successful exploitation allows execution of arbitrary code.

15) Some errors in the DHTML implementation can be exploited to cause a memory corruption.

Successful exploitation may allow execution of arbitrary code.

16) An integer overflow error in the processing of the CSS letter-spacing property can be exploited to cause a heap-based buffer overflow.

Successful exploitation allows execution of arbitrary code.

Some of the others might be safety issues as well, but it takes quite a bit of digging to figure these things out.

14 April 2006 by trevor #