Dynamisch geladener Code
Inzwischen bin ich so weit, daß ich viele Unix-Kommandozeilenprogramme zwar nützlich finde, aber in einem größeren Maßstab als unhandlich und schlecht wiederzuverwenden ansehe. Das liegt daran, daß das Konzept der Pipeline und der Kommandozeile zwar sehr mächtig sind, insbesondere wenn man sie mit einer guten Shell verwendet, aber einen nur so weit bringen.
Manchmal muß man doch richtigen Code schreiben, und wenn man dann den Compiler oder auch nur eine Scriptsprache schwingen muß, dann nützen einem die ganzen Kommandozeilen-Utilities gar nichts mehr.
Ja, es geht sogar so weit, daß sich diese ganzen Hilfsmittel als
gefährlich erweisen, wenn irgendein Schlaumeier in seiner
Gedankenlosigkeit Benutzereingaben und Kommandozeilenbefehle
zusammenmischt und dann ohne das Gehirn einzuschalten an
system() oder popen() übergibt. Die Geschichte von PHP und
Perl ist voll von solchen bedauerlichen Betriebsunfällen und
tausende von deface-ten Webseiten existieren, um Zeugnis davon
abzulegen.
Recode ist so ein Utilitiy gewesen, daß ich nützlich gefunden hätte, wenn ich es - damals - in den nn hätte einbauen können. Aber eine librecode gab es nicht - immerhin hat man einen Bugreport irgendwann erhört und eine solche erzeugt und so war es dann ganz einfach, die entsprechende PHP Extension zu schreiben.
Tidy ist ebenso ein Fall, der als Bibliothek sehr viel nützlicher gewesen wäre als als Kommandozeilenprogramm, und immerhin gibt es inzwischen auch eine Libtidy, auch wenn Suse Tidy per Default ohne diese baut und man daher das Suse-Paket erst einmal durch was richtiges ersetzen muß, bevor man sich ein zeitgemäßes PHP5 übersetzt.
Es gibt eine ganze Reihe von Programmen, die ich ebenfalls sehr viel lieber als Bibliotheken sehen würde statt als Standalone-Programme - allen voran den C-Compiler selber. Wie coole Sachen könnte man machen, stünde einem Funktionalität wie die Folgende bereit.
char *code = "void function(void) { printf(\"Hello, World\n\"); }";
void (*f)(void);
PARSETREE_T *t = parse(code);
EXEC_T *e = compile(t);
f = find_symbol(e, "function");
if (f) f();
Oder bin ich der einzige, der so etwas cool finden würde?
Aber auch ohne die Rekursion der Bibliothekserzeugung durch Bibliotheken kann man nützliche Dinge tun. Und das geht so…
Ein Stück monolithischer Code
#include <stdio.h>
int func(int para) {
int result;
printf("Entering func(%d)\n", para);
result = 3 * para;
printf("Leaving func(%d) = %d\n", para, result);
return result;
}
int main(int argc, char *argv[]) {
printf("main start\n");
printf("Calling func(4) = %d\n", func(4));
printf("main end\n");
return 0;
}
Das ist ein mächtig aufregendes Programm: Es hat eine Funktion
func, die ihren numerischen Eingabewert mit drei multipliziert
und zurückgibt. Es besteht aus einem Stück und ist trivial zu
übersetzen und auszuführen:
.PHONY: clean
prog: prog.c
cc -Wall -o prog prog.c
clean:
rm prog
Zwei einzelne Module
Für so ein kleines Testprogramm wie dieses ist das ausreichend, aber wenn
Programme größer werden, wollen wir sie aufteilen. Wir bekommen drei
Teilprogramme. Das erste, func.c, enthält unsere Rechenfunktion:
#include <stdio.h>
#include "func.h"
int func(int para) {
int result;
printf("Entering func(%d)\n", para);
result = 3 * para;
printf("Leaving func(%d) = %d\n", para, result);
return result;
}
Der zweite Teil, prog.c, ruft diese Funktion nun auf:
#include <stdio.h>
#include "func.h"
int main(int argc, char *argv[]) {
printf("main start\n");
printf("Calling func(4) = %d\n", func(4));
printf("main end\n");
return 0;
}
Der dritte Teil, func.h, ist winzig klein:
extern int func(int para);
Die "extern-Anweisung in dieser Include-Datei muß in prog.c eingebunden
werden. Sie macht dem Compiler, der prog.c übersetzt, klar, daß es eine
Funktion func() gibt, und welche Parameter sie ergibt sowie welches Ergebnis
sie liefert. Ohne diese Include-Datei würde der Compiler nicht wissen, daß
es eine solche Funktion gibt und einen Fehler generieren. Mit dem Include
vertagt er seine Entscheidung auf später, und generiert lediglich eine
“undefined reference” auf die Funktion, die dann zu einem späteren Zeitpunkt
gefunden und gelinkt werden muß.
Bevor wir uns das genauer ansehen, hier erst einmal das Makefile:
prog: prog.o func.o
cc -o prog $^
.PHONY:
clean
.c.o:
cc -Wall -c $<
clean:
rm -f *.o prog .dependencies
.dependencies:
cc -MM *.c > .dependencies
include .dependencies
Ein Testlauf:
kris@valiant:~/Source/dlopen/02-multifile> make clean
rm -f *.o prog .dependencies
kris@valiant:~/Source/dlopen/02-multifile> make
Makefile:18: .dependencies: Datei oder Verzeichnis nicht gefunden
cc -MM *.c > .dependencies
cc -Wall -c prog.c
cc -Wall -c func.c
cc -o prog prog.o func.o
kris@valiant:~/Source/dlopen/02-multifile> ./prog
main start
Entering func(4)
Leaving func(4) = 12
Calling func(4) = 12
main end
Unser Makefile generiert also mit mehreren einzelnen
Compileraufrufen eine prog.o und eine func.o-Datei. Ein
dritte Aufruf fügt dann prog aus prog.o und func.o
zusammen.
Wenn wir einmal einen genaueren Blick auf diese Dateien werden, erkennen wir, wie das funktioniert:
kris@valiant:~/Source/dlopen/02-multifile> nm func.o
00000000 T func
U printf
kris@valiant:~/Source/dlopen/02-multifile> nm prog.o
U func
00000000 T main
U printf
Die Datei prog.o enthält ein U func, ein “undefined symbol”
für die Funktionen func und printf. Sie definiert ein Symbol
main.
Die Datei func.o enthält ebenfalls ein “undefined symbol” für
printf, und definiert ein Symbol func. Durch das
Zusammenfügen beider Dateien wird das undefinierte Symbol func
mit der Definition für func aufgefüllt.
Es bleibt jetzt noch die Definition von printf zu erfüllen -
dies geschieht mit der libc, die jedem C-Programm automatisch
zugeügt wird, wenn man dies nicht abbestellt.
Der C-Startupcode, der sich auch um die Parameterbehandlung mit
argc und argv kümmert, ruft dann main auf. Er kann dies, weil
main ein definiertes (und exportiertes) Symbol ist, sodaß er
die Funktion finden kann.
Eine statische Bibliothek bauen und verwenden
Wir können dieses Code nun ohne Änderung verwenden, um eine statische Bibliothek zu bauen und zu verwenden. Dazu müssen wir lediglich die Zusammenbauanweisung, das Makefile, anpassen.
Unser neues Makefile sieht so aus:
prog: prog.o libfunc.a
cc -o prog prog.o -L. -lfunc
.PHONY:
clean
.c.o:
cc -Wall -c $<
libfunc.a: func.o
ar rcs $@ $?
clean:
rm -f *.o *.a prog .dependencies
.dependencies:
cc -MM *.c > .dependencies
include .dependencies
und es tut dies:
kris@valiant:~/Source/dlopen/03-staticlib> make
Makefile:19: .dependencies: Datei oder Verzeichnis nicht gefunden
cc -MM *.c > .dependencies
cc -Wall -c prog.c
cc -Wall -c func.c
ar rcs libfunc.a func.o
cc -o prog prog.o -L. -lfunc
Wie zuvor übersetzen wir unsere beiden .c-Dateien in .o-Dateien.
Alle Bibliotheksmodule fügen wir nun in eine Bibliothek
libfunc.a ein. Hier ist dies nur eine Datei, func.o, aber in
einem richtigen Projekt können das sehr viele Dateien sein.
Zum Erzeugen der Bibliothek verwenden wir den Archiver, ar.
Mit der Option r (Replace, also entweder einfügen oder
aktualisieren von Bibliotheksmodulen) fügen wir func.o in die
neue Bibliothek ein.
Mit Hilfe der Suboption c (Create, Anlegen der Bibliothek
bei Bedarf) sorgen wir dafür, daß die Bibliothek auch erzeugt
wird, wenn sie noch nicht existiert.
Die Suboption s erzeugt einen Objektindex im Archiv oder
aktualisiert diesen. Dies erleichtert dem Linker später die
Arbeit, wenn er das Programm aus Bibliotheksmodulen
zusammenbauen muß.
Unser Programm-Modul prog.o enthält nun ein undefined Symbol,
func. Mit der Option -L setzen wir den Suchpfad für
Bibliotheken, und zwar auf ., das aktuelle Verzeichnis. Dort
suchen wir mit -lfunc nach der Bibliothek libfunc.a.
Alle .o-Dateien in der libfunc.a werden durchsucht. Wenn eine von
ihnen das gesuchte Symbol func enthält, wird diese .o-Datei
dem Programm zugefügt. Dadurch wird func von der Liste der
undefined symbols gestrichen und es werden ggf. weitere
undefined symbols der Liste hinzugefügt, nämlich diejenigen, die
das Modul func.o selber mitbringt, wenn es dem Programm
hinzugefügt wird - in unserem Beispiel printf. Aber printf
war ja sowieso schon auf der Liste der undefinierten Symbole,
denn es wird ja auch in prog.o verwendet.
Es ist wichtig, eine Bibliothek so zu schreiben, daß sie aus vielen kleinen Objektdateien besteht - jeweils eine Funktion pro Objektdatei. Das muß so sein, weil der Linker für jedes undefined symbol die Objektdatei aus dem Archiv extrahiert und dem Programm hinzufügt, die eine Definition für das gesuchte Symbol enthält. Wenn die Objektdateien groß sind und viele Funktionen enthalten, dann werden unserem Endprogramm unter Umständen Funktionen zugefügt, die wir gar nicht brauchen, weil sie in derselben Objektdatei stehen wie eine Funktion, die wir brauchen. Unsere Programme werden dann unnötig groß.
Dynamische Bibliotheken
Bei statischen Bibliotheken enthält nun jedes Programm, das wir
schreiben und in dem wir func verwenden, eine Kopie von
func. Wenn wir drei oder vier von diesen Programmen zugleich
starten, dann stehen auf dem Rechner drei oder vier Kopien von
func im Speicher.
Das muß nicht so sein. Wir können - wieder ohne Code zu ändern - unser Programm so bauen, daß es stattdessen dynamische Bibliotheken verwendet. Eine dynamische Bibliothek wird immer als Ganzes geladen, steht dafür aber nur einmal im Speicher. Wenn also drei oder vier verschiedene Programme die Bibliothek verwenden, wird sie zwar für jedes dieser Programme in dessen Speicherbereich eingeblendet, verbraucht dafür aber nur einmal physikalischen Speicher.
Damit das funktioniert, ändern wir das Makefile noch einmal ab:
prog: prog.o libfunc.so
cc -o prog prog.o -L`pwd` -lfunc -Wl,-rpath `pwd`
.PHONY:
clean
.c.o:
cc -Wall -c $<
libfunc.so: func.o
cc -rdynamic -shared -o libfunc.so func.o
clean:
rm -f *.o *.a *.so prog .dependencies
.dependencies:
cc -MM *.c > .dependencies
include .dependencies
Der Build sieht jetzt so aus:
kris@valiant:~/Source/dlopen/04-dynamiclib> make
Makefile:20: .dependencies: Datei oder Verzeichnis nicht gefunden
cc -MM *.c > .dependencies
cc -Wall -c prog.c
cc -Wall -c func.c
cc -rdynamic -shared -o libfunc.so func.o
cc -o prog prog.o -L`pwd` -lfunc -Wl,-rpath,`pwd`
Hier werden die Objektmodule ohne eigene main-Funktion nicht
mit ar in eine lib*.a-Datei überführt, sondern mit einem
cc-Aufruf in eine .so-Datei umgewandelt.
So wie man nm auf Objektdateien (*.o) und Bibliotheken
(*.a) anwenden kann, kann man mit objdump -T libfunc.so
eine Liste der in der .so-Datei definierten Symbole bekommen -
leider bekommt man neben den interessanten Informationen auch
noch eine ganze Menge Verwaltungsklimbim angezeigt, sodaß man
das Ergebnis ein wenig filtern muß, bevor man es sinnvoll lesen
kann.
Der eigentliche Build-Aufruf ist
cc -o prog prog.o -L`pwd` -lfunc -Wl,-rpath,`pwd`
Die Optionen -L und -l funktionieren genau wie bei
statischen Bibliotheken. Mit der Option -Wl wird eine Option
an den Linker weitergegeben, den wir mit -rpath,\pwd``
instruieren, das aktuelle Verzeichnis als Suchpfad für die
dynamischen Bibliotheken im resultierenden Binary mit zu
vermerken.
Wenn wir das nicht täten, würde libfunc.so nicht gefunden
werden, solange wir sie nicht in einem der in
/etc/ld.so.conf genannten Verzeichnisse installieren und einmal
ldconfig aufrufen.
Wer dem Linker bei der Arbeit zuschauen will, der kann dies tun,
indem er die Shell-Variable LD_DEBUG setzt und exportiert. Der
Wert help zeigt einem, auf was für Werte man LD_DEBUG setzen
kann:
kris@valiant:~/Source/dlopen/04-dynamiclib> export LD_DEBUG=help
kris@valiant:~/Source/dlopen/04-dynamiclib> ./prog
Valid options for the LD_DEBUG environment variable are:
libs display library search paths
reloc display relocation processing
files display progress for input file
symbols display symbol table processing
bindings display information about symbol binding
versions display version dependencies
all all previous options combined
statistics display relocation statistics
unused determined unused DSOs
help display this help message and exit
To direct the debugging output into a file instead of standard output
a filename can be specified using the LD_DEBUG_OUTPUT environment variable.
dlopen()
Manchmal kann man zur Compilezeit noch nicht vorhersagen, welche Module das laufende Programm später einmal benötigen wird.
Speziell Programme mit Plugin-Architekturen haben den Bedarf,
.so-Dateien zur Laufzeit anziehen zu können, um so ihre
Funktionalität durch das Laden von Plugins zu erweitern. Während
statisch eingebundene .so-Dateien keine Änderungen am Code
notwendig machen, ist für dynamisch geladene Dateien ein wenig
Änderung notwendig - allerdings nur auf der ladenden Seite.
Auf der Seite des Bibliothekscodes, in unserem Falle also
func.c, func.o und libfunc.so, ist keine Änderung
notwendig.
Das Makefile sieht nun jedoch so aus:
all: prog libfunc.so
prog: prog.o
cc -o prog prog.o -ldl
.PHONY:
clean all
.c.o:
cc -Wall -c $<
libfunc.so: func.o
cc -rdynamic -shared -o libfunc.so func.o
clean:
rm -f *.o *.a *.so prog .dependencies
.dependencies:
cc -MM *.c > .dependencies
include .dependencies
Wir haben nun also zwei unabhängige Targets beim Build: Die
.so-Datei und das Programm, das sie verwendet, teilen keine
gemeinsame Abhängigkeit mehr. Das Programm, prog, wird nun
auch nicht mehr gegen die .so-Datei gelinkt. Stattdessen wird
mit -ldl die libdl eingebunden, die uns die Funktionen
dlopen(), dlsym() und dlclose() bereitstellt.
Der Code in prog.c sieht nun so aus:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <dlfcn.h>
#define LIBNAME "./libfunc.so"
typedef int (*func_t)(int);
int main(int argc, char *argv[]) {
func_t f;
char *error_msg;
void *libhandle = NULL;
printf("main start\n");
/* .so oeffnen */
libhandle = dlopen(LIBNAME, RTLD_LAZY);
if (!libhandle) {
fprintf(stderr, "dlopen(%s, RTLD_LAZY failed: %s\n",
LIBNAME,
dlerror()
);
exit(2);
}
printf("dlopen() = %p\n", libhandle);
/* func() finden */
error_msg = dlerror();
f = dlsym(libhandle, "func");
error_msg = dlerror();
if (error_msg) {
fprintf(stderr, "dlsym(%p, \"func\") failed: %s\n",
libhandle,
error_msg
);
exit(3);
}
/* func() aufrufen */
printf("Calling func(4) = %d\n", f(4));
/* .so droppen */
dlclose(libhandle);
printf("main end\n");
return 0;
}
Dieser Code definiert eine Variable f vom Typ “Zeiger auf eine
Funktion, die ein int liefert und einen int-Parameter annimmt”.
Er lädt mit dlopen() die libfunc.so ein. Wenn dies gelingt,
steht ein Handle für die Bibliothek zur Verfügung. Mit dlsym()
können wir mit Hilfe des Handles in dieser Bibliothek nach der
dem Symbol func suchen und bekommen so einen Zeiger auf func
in f abgelegt oder nicht.
Man beachte das Errorchecking für das Ergebnis von dlsym() nach
Lehrbuch - das Interface von dlsym() ist mehr als bekloppt nicht
sehr schön designed.
Wir können f dann ganz normal aufrufen. dlclose() entlädt
das Plugin dann wieder.
Wenn mehr Leute sich angewöhnen würden, ihre Programme in Form von Bibliothek und Kommandozeilenwrapper zu schreiben, wäre es sehr viel leichter, Code in Form von Bibliotheken in Sprachkerne wie PHP oder in andere Programme einzubinden. Technisch ist das nicht sehr schwer, solange man sich die Mühe macht, die Infrastruktur drumherum in Form von Makefiles und Include-Dateien ordentlich zu erstellen.
Material
Das Program Library Howto zeigt den ganzen Kram noch einmal in aller Ausführlichkeit. Ein PDF von Ulrich Drepper diskutiert die dabei ablaufenden Interna.
Das C++ dlopen Mini-Howto beschreibt, wie das ganze mit C++ zu bewerkstelligen ist. James Norton baut da in Dynamic Class Loading in C++ sogar einen schönen Wrapper drumherum.
Dynamic C++ Classes - Code Distribution ist die Downloadseite der dynamic-class library für C++. Das Paper “Dynamic C++ classes: A lightweight mechanism to update code in a running program” von Gísli Hjálmtýsson and Bob Gray beschreibt den Hintergrund.