151-byte static Linux binary in Rust

http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-static-linux-binary-in-rust.html

by adito • 12 years ago

191 57 12 years ago

mainisusuallyafunction.blogspot.com

userbinator2• 12 years ago

That main() can still be improved... try this:

    push 1
    pop eax
    mov edi, eax
    mov esi, 400008h
    push 7
    pop edx
    syscall
    push 3ch
    pop eax
    xor edi, edi
    syscall

It should be 10 bytes shorter.

ekimekim• 12 years ago

Yes, but the point was that it could be done in rust, using rust's language features (type safety and so forth). Making your main inline assembly isn't really using the language very much.

omega_rythm• 12 years ago

You really should have a look at the rust code this guy wrote. I would not call that last optimization type safe.

userbinator2• 12 years ago

From the Github page: https://github.com/kmcallister/tiny-rust-demo

All of the machine code comes out of rustc. (Although all of the instructions that survive optimization went in as inline assembly.)

So while his main() is written in (unsafe) Rust, he's basically using it as a macroassembler.

taralx• 12 years ago

LLVM currently does not optimize for size, so things like the small-integer push/pop trick aren't goign to happen.

tdicola• 12 years ago

That is really impressive. Now for comedy, someone find the size of a similar program in Go.

Alupis2• 12 years ago

Now for comedy, someone find the size of a similar program in Go

As far as I know, Go statically links the runtime into the binary (including the garbage collector, the scheduling system and more)... so for a small program like this sample, it will appear to be abnormally bloated. If it were a larger, more complex example, then the binary size wouldn't change as drastically (and on a surface level might appear to be more justifiable).

erglkjahlkh• 12 years ago

It is also bad in following dependencies, and links the whole libraries. The result is like spaghetti, import on library and half of the standard libraries come with it. Some optimizations have been already done to prevent that, but the work is going to be still in progress for several versions.

f2f• 12 years ago

oops, sorry, downvote brigade. :)

Alupis2• 12 years ago

reminds me a bit of the "Creating Really Teensy ELF Executables" writeup[1], which got down to 45 bytes.

But honestly... does it really matter how small your executable is? I'd care a lot more about performance characteristics than binary size.

[1] http://www.muppetlabs.com/~breadbox/software/tiny/teensy.htm...

jeremyjh• 12 years ago

It may matter in some embedded applications (for which chipsets there is not even Rust compiler support yet) but the point is to show off how much low-level control you have over code-generation, and that no run-time is needed.

dbaupp2• 12 years ago

Cache Rules Everything Around Me, and bloated executables generally put more stress on the instruction cache, resulting in poorer performance.

Of course, this is just an approximate general rule, and extremely small binaries (and generally any "pointless" experimentation) like this are mainly interesting from a learning point of view (or for small embedded microcontrollers), e.g. understanding syscalls and program start-up, and, for the write-up you link, the ELF format. (Not everything has to be inherently useful for an actual task.)

semi-extrinsic• 12 years ago

I'm going to have to steal your opening quote, for times when I have to keep it real*8. Source?

jarfil• 12 years ago

These exercises may lack practical value, except perhaps to the virus makers, but they do kind of prove there is no extraneous overhead required by the language.

So we already knew that about assembler, now we also know Rust can be twisted quite close to that too.

smosher_• 12 years ago

To play the advocate, given that by default compilation produces a binary that includes over 2KB of Lovecraft quotes¹, this article at least serves to reassure people that you can produce a compact binary with Rust.

¹ https://github.com/rust-lang/rust/issues/13871

sjwright• 12 years ago

does it really matter how small your executable is?

It demonstrates how much control you can choose to exert over your compiled program.

EliRivers• 12 years ago

I'd care a lot more about performance characteristics than binary size

The key word here is I'd. The programming world is vast, and the range of hardware is likewise vast. So, so vast. Really huge. Pick a restriction you don't have to worry about; someone else out there does.

starmole• 12 years ago

Wow. This is seriously impressive. Rust looks like it actually might be capable as a systems programming tool to match C. I have to learn more about it now! :)

0xFFC2• 12 years ago

dude its great , but not that good, at least not yet .

zxcdw• 12 years ago

Care to elaborate why do you think so?

yazaddaruvala• 12 years ago

I'd actually love to ask Linus' on his opinion of the practical uses of Rust in the Linux kernel. Does he think it could have a place, if not, why? Can those issues be addressed, etc?

Even if that means him dismissing me/my question entirely lol.

0xFFC2• 12 years ago

Rust seems very promising language , but why on earth should any one use rust in kernel development ? as far as I see this link is just calling write system call from rust program (which is very good) , but don't have anything to do with linus or kernel internal. and if you mean some thing like scripting in kernel ( i think openbsd ddne it with lua ) there is more viable and simpler choice than rust , like lua.

jnbiche• 12 years ago

but why on earth should any one use rust in kernel development

Because that's explicitly one of the things Rust was developed for.

Here's a whole list of kernels and other OS projects that have been created using Rust:

https://github.com/rust-lang/rust/wiki/Operating-system-deve...

david-given• 12 years ago

Because it allows (in some situations) dynamic memory allocation where the compiler can reason about when the memory becomes unused, thus guaranteeing that it's freed. In other words, you get to use algorithms which allocate off the heap without risking a memory leak. Plus a whole bunch of other useful features like Lisp-style structural macros, parametric polymorphism, compile time bounds checking, and other awesome stuff stolen from the functional programming world.

hga• 12 years ago

I gather LLVM has too few backends, and fewer quality ones, to be suitable for such a general purpose OS.

As I recall Rust is currently targeting only Intel and ARM backends.

And it's way too early to see if it'll make it.

CyberShadow• 12 years ago

I did something similar in D/Win32:

http://forum.dlang.org/post/qcbicxrtmjmwiljsyhdf@forum.dlang...

The PE format is rather bulkier than ELF, though.

Keyframe2• 12 years ago

I just had a look. Installed nightly Rust on OSX and ran through it a hello world program - 307K! HW in C with gcc 4.2.1 (LLVM) makes 8.7K.

epdtry• 12 years ago

Rust produces statically linked binaries by default, while GCC and Clang default to dynamic linking. For a better comparison, pass `-static` to GCC/Clang, or pass `-C prefer-dynamic` to rustc.

On Linux, with dynamic linking:

  rustc: 8656 bytes
  clang: 6960 bytes
  gcc:   6688 bytes

Keyframe2• 12 years ago

Ah of course, thanks! That makes sense. Since I'm on OSX and -static doesn't work with GCC (libs provided aren't static) - I'll believe it instead. Rustc is now 9K, which is really close to 8.7 of GCC.

swetland4• 12 years ago

Is it possible to make actual static binaries in rust? By default it compiles in the rust libraries, but depends on glibc and friends (and is not actually a static binary) -- at least with tip of tree rust from yesterday.

swetland4• 12 years ago

This is cute, but is there a way to actually create static binaries with the standard tooling and not jumping through hoops?

Hello World in Rust with tip of tree (as of yesterday) is a ~500K binary that depends on glibc and friends.

Switching from println!() to std::io...write_str() actually made it larger!

steveklabnik4• 12 years ago

You can't static link glibc, so our static binaries still have a dynamic dependency on it.

cowsandmilk• 12 years ago

and for many, there are legal issues with statically linking glibc due to its license.

swetland4• 12 years ago

Is there a process for making a fully static binary (say if I were to substitute an alternate libc, or provide my own low level wrappers for syscalls, or whatnot)?

ChickeNES• 12 years ago

Any reason one couldn't use musl instead for static linking? (http://www.musl-libc.org/)

151-byte static Linux binary in Rust

Related Stories