GCC La réduction binaire ballonnement - Side Effect étrange

Question

Le Weirdness

J'ai compilé en utilisant buffers Google Protocole sans paramètres supplémentaires pour un « enfler » compiler et compiler avec la commande suivante ./configure CXXFLAGS="-ffunction-sections -fdata-sections". un du-h révèle:

120K ./bloat/bin 
124K ./bloat/include/google/protobuf/io 
8.0K ./bloat/include/google/protobuf/compiler/java 
12K ./bloat/include/google/protobuf/compiler/python 
8.0K ./bloat/include/google/protobuf/compiler/cpp 
128K ./bloat/include/google/protobuf/compiler 
52K ./bloat/include/google/protobuf/stubs 
848K ./bloat/include/google/protobuf 
852K ./bloat/include/google 
856K ./bloat/include 
12K ./bloat/lib/pkgconfig 
37M ./bloat/lib 
38M ./bloat 
20K ./unbloat/bin 
124K ./unbloat/include/google/protobuf/io 
8.0K ./unbloat/include/google/protobuf/compiler/java 
12K ./unbloat/include/google/protobuf/compiler/python 
8.0K ./unbloat/include/google/protobuf/compiler/cpp 
128K ./unbloat/include/google/protobuf/compiler 
52K ./unbloat/include/google/protobuf/stubs 
848K ./unbloat/include/google/protobuf 
852K ./unbloat/include/google 
856K ./unbloat/include 
12K ./unbloat/lib/pkgconfig 
15M ./unbloat/lib 
16M ./unbloat 
53M . 

Drill Down:

ls -gGh bloat/lib/ 
    total 37M 
    -rw-r--r-- 1 13M 2010-09-07 13:57 libprotobuf.a 
    -rwxr-xr-x 1 986 2010-09-07 13:57 libprotobuf.la 
    -rw-r--r-- 1 1.6M 2010-09-07 13:57 libprotobuf-lite.a 
    -rwxr-xr-x 1 1021 2010-09-07 13:57 libprotobuf-lite.la 
    lrwxrwxrwx 1 25 2010-09-07 13:57 libprotobuf-lite.so -> libprotobuf-lite.so.6.0.0 
    lrwxrwxrwx 1 25 2010-09-07 13:57 libprotobuf-lite.so.6 -> libprotobuf-lite.so.6.0.0 
    -rwxr-xr-x 1 771K 2010-09-07 13:57 libprotobuf-lite.so.6.0.0 
    lrwxrwxrwx 1 20 2010-09-07 13:57 libprotobuf.so -> libprotobuf.so.6.0.0 
    lrwxrwxrwx 1 20 2010-09-07 13:57 libprotobuf.so.6 -> libprotobuf.so.6.0.0 
    -rwxr-xr-x 1 5.5M 2010-09-07 13:57 libprotobuf.so.6.0.0 
    -rw-r--r-- 1 12M 2010-09-07 13:57 libprotoc.a 
    -rwxr-xr-x 1 1.1K 2010-09-07 13:57 libprotoc.la 
    lrwxrwxrwx 1 18 2010-09-07 13:57 libprotoc.so -> libprotoc.so.6.0.0 
    lrwxrwxrwx 1 18 2010-09-07 13:57 libprotoc.so.6 -> libprotoc.so.6.0.0 
    -rwxr-xr-x 1 4.6M 2010-09-07 13:57 libprotoc.so.6.0.0 
    drwxr-xr-x 2 4.0K 2010-09-07 13:57 pkgconfig 
    ls -gGh unbloat/lib/ 
    total 15M 
    -rw-r--r-- 1 5.8M 2010-09-07 14:03 libprotobuf.a 
    -rwxr-xr-x 1 988 2010-09-07 14:03 libprotobuf.la 
    -rw-r--r-- 1 764K 2010-09-07 14:03 libprotobuf-lite.a 
    -rwxr-xr-x 1 1023 2010-09-07 14:03 libprotobuf-lite.la 
    lrwxrwxrwx 1 25 2010-09-07 14:03 libprotobuf-lite.so -> libprotobuf-lite.so.6.0.0 
    lrwxrwxrwx 1 25 2010-09-07 14:03 libprotobuf-lite.so.6 -> libprotobuf-lite.so.6.0.0 
    -rwxr-xr-x 1 393K 2010-09-07 14:03 libprotobuf-lite.so.6.0.0 
    lrwxrwxrwx 1 20 2010-09-07 14:03 libprotobuf.so -> libprotobuf.so.6.0.0 
    lrwxrwxrwx 1 20 2010-09-07 14:03 libprotobuf.so.6 -> libprotobuf.so.6.0.0 
    -rwxr-xr-x 1 2.7M 2010-09-07 14:03 libprotobuf.so.6.0.0 
    -rw-r--r-- 1 3.7M 2010-09-07 14:04 libprotoc.a 
    -rwxr-xr-x 1 1.1K 2010-09-07 14:04 libprotoc.la 
    lrwxrwxrwx 1 18 2010-09-07 14:04 libprotoc.so -> libprotoc.so.6.0.0 
    lrwxrwxrwx 1 18 2010-09-07 14:04 libprotoc.so.6 -> libprotoc.so.6.0.0 
    -rwxr-xr-x 1 1.3M 2010-09-07 14:04 libprotoc.so.6.0.0 
    drwxr-xr-x 2 4.0K 2010-09-07 14:03 pkgconfig 

La question

Je n'ai pas modifié les scripts de compilation pour effectuer une "--gc-sections" pendant la liaison, shouldn donc » t la construction unbloat soit la même sinon plus grande? Qu'est-ce qui a causé la réduction de la taille?

Contexte

Je compile une bibliothèque de bas niveau avec gcc au moment et à la bibliothèque est un 2.5MB ginormous et 970KB dépouillé-rayés. C'est inacceptable, et j'ai besoin d'enlever le code mort - je dépends de OpenSSL, des tampons de protocole et de 3 bibliothèques de Boost, et je lierai statique les 2 derniers dans ma bibliothèque. Les deux bibliothèques liées statiquement devront être compilées avec le "-ffunction-sections -fdata-sections" pour moi d'enlever le code mort.

Question connexe

Mon next question est sur la façon de spécifier la racine utilisée pour éliminer le code mort.

Answer 1

Je crains que le gain n'ait rien à voir avec -ffunction-sections -fdata-sections: lorsque vous avez spécifié CXXFLAGS="-ffunction-sections -fdata-sections" sur la ligne de commande configure, vous avez écrasé les indicateurs par défaut qui étaient -O2 -g -DNDEBUG. En conséquence, votre code a été compilé sans optimisations.

Vous devriez refaire votre test avec CXXFLAGS="-ffunction-sections -fdata-sections -O2 -g -DNDEBUG" et vous obtiendrez les résultats attendus (c'est-à-dire identiques).

Answer 2

avec -ffunction-sections provoque Compiler toutes les fonctions à émettre dans sa propre section, et qui provoque chaque fichier d'objet pour devenir plus grand (au lieu de simplement .text section, vous avez maintenant .text.foo, .text.bar, etc.). Idem pour -fdata-sections. Donc le résultat que vous avez est exactement ce qui est attendu.

Mais ne devrait pas prendre soin de la taille de votre zone de construction. Qu'est-ce que devrait se soucient de la taille de votre exécutable final (ou bibliothèque partagée). Avec les indicateurs que vous avez spécifiés, l'exécutable "bloat" peut être encore plus grand (mais probablement pas beaucoup). Maintenant, ajoutez -Wl,--gc-sections, et votre "bloat" exécutable deviendra nettement plus petit.