GCC Zmniejszenie Binary uwędzić - Strange Side Effect

Question

Weirdness

Mam skompilowany przy użyciu buforów protokołów Google żadnych dodatkowych parametrów dla „uwędzić” skompilować i skompilować za pomocą następującego polecenia ./configure CXXFLAGS="-ffunction-sections -fdata-sections". du-h ujawnia:

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 . 

drążyć:

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 

Kwestii

nie zmieniły skryptów kompilacji aby przeprowadzić "--gc-sections" podczas łączenie, dlatego powinnaś t konstrukcja unbloat jest taka sama, jeśli nie większa? Co spowodowało zmniejszenie rozmiaru?

Tło

ja kompilowania biblioteki niskopoziomowe z GCC w tej chwili, a biblioteka jest ginormous 2.5MB unstriped i 970KB usuwane. Jest to niedopuszczalne i muszę usunąć martwy kod - polegam na OpenSSL, buforach protokołów i 3 bibliotekach z Boost, a ja statycznie połączę ostatnie 2 z moją biblioteką. Dwie statycznie połączone biblioteki będą musiały zostać skompilowane za pomocą "-ffunction-sections -fdata-sections", aby usunąć martwy kod.

pokrewne Pytanie

My next question jest o tym, jak określić korzeń stosowany do usuwania martwego kodu.

Answer 1

Obawiam się, że zysk nie ma nic wspólnego z -ffunction-sections -fdata-sections: po określeniu CXXFLAGS="-ffunction-sections -fdata-sections" w wierszu polecenia configure, nadpisałeś domyślne flagi, które były -O2 -g -DNDEBUG. W związku z tym Twój kod został skompilowany bez optymalizacji.

Powtórz test z CXXFLAGS="-ffunction-sections -fdata-sections -O2 -g -DNDEBUG", a uzyskasz oczekiwane (tj. Identyczne) wyniki.

Answer 2

Kompilacja z -ffunction-sections powoduje każdą funkcję być emitowane w swojej sekcji, a to powoduje, że każdy plik obiektu, aby stać się większe (zamiast tylko .text sekcji, masz teraz .text.foo, .text.bar, itd.). To samo dotyczy -fdata-sections. Rezultat jest dokładnie taki, jak się spodziewasz.

Ale ty nie powinieneś się martwić, jak duży jest twój obszar budowy. To, co powinieneś zadać, to: , jak duży jest twój końcowy plik wykonywalny (lub biblioteka współdzielona).

Po określeniu flag, plik "rozdęty" może być jeszcze większy (ale prawdopodobnie nie za dużo). Teraz dodaj -Wl,--gc-sections, a plik wykonywalny "rozdęcie" stanie się znacznie mniejszy.