Warum und wie sind einige gemeinsam genutzte Bibliotheken lauffähig, als wären sie ausführbar?

Diese Bibliothek hat einen main() Funktion oder gleichwertiger Einstiegspunkt und wurde so kompiliert, dass es sowohl als ausführbares als auch als gemeinsam genutztes Objekt nützlich ist.

Hier ist ein Vorschlag, wie das geht, obwohl es bei mir nicht funktioniert.

Hier ist eine weitere Antwort auf eine ähnliche Frage zu S.O., die ich schamlos plagiieren, optimieren und ein wenig erklären werde.

Zuerst die Quelle für unsere Beispielbibliothek, test.c :

#include <stdio.h>                  

void sayHello (char *tag) {         
    printf("%s: Hello!\n", tag);    
}                                   

int main (int argc, char *argv[]) { 
    sayHello(argv[0]);              
    return 0;                       
}                   

Kompilieren Sie das:

gcc -fPIC -pie -o libtest.so test.c -Wl,-E

Hier kompilieren wir eine gemeinsam genutzte Bibliothek (-fPIC ), aber dem Linker mitteilen, dass es sich um eine reguläre ausführbare Datei handelt (-pie ) und seine Symboltabelle exportierbar zu machen (-Wl,-E ), sodass sie sinnvoll verlinkt werden kann.

Und zwar file wird sagen, es ist ein gemeinsam genutztes Objekt, es funktioniert als ausführbare Datei:

> ./libtest.so 
./libtest.so: Hello!

Jetzt müssen wir sehen, ob es wirklich dynamisch verknüpft werden kann. Ein Beispielprogramm, program.c :

#include <stdio.h>

extern void sayHello (char*);

int main (int argc, char *argv[]) {
    puts("Test program.");
    sayHello(argv[0]);
    return 0;
}

Mit extern erspart uns das Erstellen eines Headers. Kompilieren Sie das jetzt:

gcc program.c -L. -ltest

Bevor wir es ausführen können, müssen wir den Pfad libtest.so hinzufügen für den dynamischen Lader:

export LD_LIBRARY_PATH=./

Jetzt:

> ./a.out
Test program.
./a.out: Hello!

Und ldd a.out zeigt die Verknüpfung zu libtest.so .

Beachten Sie, dass ich bezweifle, dass glibc tatsächlich so kompiliert wird, da es wahrscheinlich nicht so portabel ist wie glibc selbst (siehe man gcc bezüglich -fPIC und -pie Schalter), aber es demonstriert den grundlegenden Mechanismus. Für die wirklichen Details müssten Sie sich das Quell-Makefile ansehen.

Lassen Sie uns in einem zufälligen glibc-Repo auf GitHub nach einer Antwort suchen. Diese Version enthält ein „Banner“ in der Datei version.c .

In derselben Datei gibt es einige interessante Punkte:die __libc_print_version Funktion, die den Text auf stdout und den __libc_main (void) ausgibt Symbol, das als Einstiegspunkt dokumentiert ist. Dieses Symbol wird also aufgerufen, wenn die Bibliothek ausgeführt wird.

Woher weiß der Linker oder Compiler genau, dass dies die Einstiegspunktfunktion ist?

Lassen Sie uns in das Makefile eintauchen. In den Linker-Flags gibt es ein interessantes:

# Give libc.so an entry point and make it directly runnable itself.
LDFLAGS-c.so += -e __libc_main

Dies ist also das Linker-Flag zum Festlegen des Einstiegspunkts für die Bibliothek. Beim Erstellen einer Bibliothek können Sie den -e function_name angeben Flag für den Linker, um ein ausführbares Verhalten zu ermöglichen. Was macht es wirklich? Schauen wir ins Handbuch (etwas veraltet, aber immer noch gültig):

the `-e' entry command-line option;
the ENTRY(symbol) command in a linker control script;
the value of the symbol start, if present;
the address of the first byte of the .text section, if present;
The address 0.