This is the mail archive of the
mailing list for the libc-ports project.
[Announce] Port of glibc to Google Native Client
- From: Mark Seaborn <mrs at mythic-beasts dot com>
- To: libc-ports at sourceware dot org
- Date: Sun, 19 Apr 2009 17:38:53 +0100 (BST)
- Subject: [Announce] Port of glibc to Google Native Client
I have been working on a port of glibc to Google Native Client. 
Some background: Native Client (NaCl for short) is a sandboxing system
for running a subset of x86 code on Linux, Windows and Mac OS X. It
is proposed as a way of running native code inside web apps. 
Native Client is a hack to get around the lack of sandboxing
facilities on these OSes. It uses x86 segmentation to constrain
memory accesses, and it has a verifier for x86 code which disallows
instructions that would be unsafe, such as syscalls. To ensure that
x86 code can be reliably disassembled, NaCl requires that all indirect
jumps are to 32-byte-aligned addresses, and instructions may not
straddle these 32 byte blocks.
Upstream NaCl uses newlib, statically linked, as its C library. It
doesn't support dynamic loading of code.
I am porting glibc to make it easier to port GNU/Linux software to
NaCl, and to make it easier to port software that requires dynamic
loading. In the long term it may be possible to run many GNU/Linux
programs after a simple recompile.
The port is at the stage where it can run simple statically-linked and
dynamically-linked executables, from the command line and from the web
browser. In particular, Python works. Use of dynamic linking
requires some changes to NaCl.
The glibc changes involved fall into two categories:
* Using a different syscall interface.
* Making the x86 code pass the verifier. For example, the "ret"
instruction is not allowed by the validator and needs to be replaced
with "pop %ecx; nacljmp %ecx". In some cases I fixed the assembly
code. In other cases I removed assembly files so that glibc would
fall back to using C implementations.
I have used the Linux-i386 build of glibc as a starting point, so the
changes are not very mergeable at present. Any advice about how to
handle what is effectively a subarchitecture of i386 would be
I am aiming to keep the ABI the same as Linux glibc (unlike Hurd
glibc, which as I understand has ABI differences). This means that
although Linux-glibc executables won't work on NaCl, NaCl-glibc
executables will work with Linux-glibc directly under Linux, outside
of the NaCl environment.
The code is available in a Git repository: