Embedded-Entwickler zirkeln um jedes Byte. Da kommen abgespeckte C-Bibliotheken wie UC-Libc und Dietlibc, schlankere Standard Template Libraries für C++ sowie GNU-Tool-kompatible Zwerge genau recht.

© Glen Jones, Fotolia.com

Die C-Bibliothek ist nach dem Kernel die maßgebliche Komponente jedes Server-, Desktop- oder Embedded-Linux-Systems. Sie bestimmt das Systemverhalten, den Funktionsumfang, die Stabilität und auch die Gesamtgröße. Die C-Bibliothek setzt auf dem Kernel auf und implementiert grundlegende Features, um Informationen mit dem Kernel auszutauschen und so Userspace-Programmen dessen Funktionalität bereitzustellen.

Dies sind zum einen Ansi-C-Funktionen wie »fopen()«, »exit()«, »free()«, »fread()«, »fwrite()« oder »malloc()«. Zum anderen etabliert die Bibliothek Funktionen, die zur C-Runtime gehören und nichts mit dem Kernel zu tun haben, etwa die String- und andere Speicher-Funktionen wie »strcpy()«, »strcmp()«, »memcpy()« und »memcmp«. Posix fordert für Unix-artige Systeme zudem Funktionen wie »open()«, »read()«, »write()«, »join()«, »fork()« oder »kill()«.

Nachdem der Kernel den Code eines Userprogramms in den Speicher geladen hat, beginnt die Arbeit der C-Bibliothek. Sie ist dafür zuständig, Datenstrukturen zu initialisieren, benötigte dynamische Bibliotheken zu laden und schließlich die »main()«-Funktion zu starten. Äquivalent dazu ruft sie beim Beenden eines Programms mit »exit()« die durch »atexit()« registrierten Funktionen auf. Ist C++ im Spiel, gilt es auch, die in C++ definierten statischen Konstruktoren und Destruktoren anzuspringen.

Kernelroutinen nutzen

Um eine Funktion des nackten Kernels in Anspruch zu nehmen, muss das System die Nummer des entsprechenden Systemaufrufs in vorgegebene CPU-Register laden und die Argumente in andere dafür vorgesehene Register beziehungsweise in den Speicher schreiben. Eine Architektur-spezifische Funktion übergibt danach die Kontrolle an den Kernel. Auf Intel-386-Systemen ist das der Software-Interrupt 0x80.

Neuere Intel-, AMD- und kompatible Prozessoren besitzen für den gleichen Zweck auch spezielle Sysenter-/Sysexit- beziehungsweise Syscall-/Sysret-Befehlskombination. Wie bei einem Software-Interrupt überantworten sie die weitere Befehlsausführung an den dafür registrierten Kernelcode. Der Vorteil der dafür dedizierten Instruktion liegt im geringeren Overhead im Vergleich zum klassischen Software-Interrupt - das spart pro Kontextswitch CPU-Zyklen. Als Äquivalent dazu verfügen Risc-CPUs über Trap-Instruktionen. Jede C-Bibliothek implementiert solche Hardware-spezifischen Details. Wie beim Startup- und Exit-Code gelingt das nur in Assembler.

Die auf Desktop- und Server-Systemen für Linux eingesetzte Glibc [1] hat den größten Funktionsumfang und wartet mit allerlei Performance-Optimierungen auf. Neben Linux unterstützt die Bibliothek auch Hurd, BSD- sowie klassische Unix-Systeme. Die Glibc hat jedoch mit über 1 MByte (auf I-386) eine stattliche Größe und disqualifiziert sich somit von vornherein für Systeme mit wenig RAM. Einen Ausweg aus dieser Misere bieten UC-Libc [2] und Dietlibc [3]. Beide freien Implementierungen sind extra für Linux-Embedded-Systeme entstanden.

UC-Libc

Die etwas ältere UC-Libc entstand anfangs speziell für den Dragonball-Prozessor aus der 6800er Familie von Motorola sowie den ARM-Coldfire-Mikrocontroller und besaß darum keinen Code für Memory Management Units (MMU). Heute unterstützt UC-Libc auch reguläre Linux-Systeme mit Speicherverwaltungseinheit, nach wie vor aber auch solche ohne - ein Vorteil.

Teilweise basiert die kleine C-Bibliothek auf dem Quellcode der Glibc, teilweise auf anderen Bibliotheken. So erreichte die UC-Libc schnell einen großen Funktionsumfang und bedient CPU-Architekturen wie AVR32, Blackfin und viele andere mehr. Mit weniger als 300 KByte (für I-386) ist die UC-Libc deutlich kleiner als die Glibc.

Embedded-Entwickler zirkeln um jedes Byte. Da kommen abgespeckte C-Bibliotheken wie UC-Libc und Dietlibc, schlankere Standard Template Libraries für C++ sowie GNU-Tool-kompatible Zwerge genau recht.