Jak usunąć nieużywane symbole C / C ++ za pomocą GCC i ld?

Muszę poważnie zoptymalizować rozmiar mojego pliku wykonywalnego ( ARMprogramowanie) i zauważyłem, że w moim obecnym schemacie kompilacji ( gcc+ ld) nieużywane symbole nie są usuwane.

Użycie arm-strip --strip-unneededdla wynikowych plików wykonywalnych / bibliotek nie zmienia rozmiaru wyjściowego pliku wykonywalnego (nie mam pojęcia dlaczego, może po prostu nie może) .

Jaki byłby sposób (jeśli istnieje) zmodyfikowania potoku budowania, tak aby nieużywane symbole zostały usunięte z pliku wynikowego?

Ja nawet nie myśleć o tym, ale mój obecny osadzony środowisko nie jest bardzo „mocny” i oszczędność nawet 500Kz 2Mwynikami w bardzo ładnym wzrost wydajności załadunku.

Aktualizacja:

Niestety obecna gccwersja, której używam, nie ma takiej -dead-stripopcji, a -ffunction-sections... + --gc-sectionsfor ldnie daje żadnej znaczącej różnicy w wynikowym wyniku.

Jestem zszokowany, że stało się to nawet problemem, ponieważ byłem pewien, że gcc + ldpowinno to automatycznie usunąć nieużywane symbole (dlaczego w ogóle muszą je zachować?).

W przypadku GCC odbywa się to w dwóch etapach:

Najpierw skompiluj dane, ale powiedz kompilatorowi, aby rozdzielił kod na oddzielne sekcje w jednostce tłumaczenia. Zostanie to zrobione dla funkcji, klas i zmiennych zewnętrznych przy użyciu następujących dwóch flag kompilatora:

-fdata-sections -ffunction-sections

Połącz jednostki tłumaczeniowe razem przy użyciu flagi optymalizacji linkera (powoduje to, że linker odrzuca sekcje bez odniesień):

-Wl,--gc-sections

Więc jeśli masz jeden plik o nazwie test.cpp, w którym zadeklarowano dwie funkcje, ale jedna z nich była nieużywana, możesz pominąć nieużywany za pomocą następującego polecenia do gcc (g ++):

gcc -Os -fdata-sections -ffunction-sections test.cpp -o test -Wl,--gc-sections

(Zauważ, że -Os to dodatkowa flaga kompilatora, która mówi GCC, aby zoptymalizować pod kątem rozmiaru)

Jeśli ten wątek wierzyć, trzeba dostarczyć -ffunction-sectionsi-fdata-sections do gcc, co wywrze każdej funkcji i obiekt danych w osobnej sekcji. Następnie dajesz i --gc-sectionsGNU ld usuwa nieużywane sekcje.

Będziesz chciał sprawdzić swoje dokumenty pod kątem wersji gcc & ld:

Jednak dla mnie (OS X gcc 4.0.1) znajduję je dla ld

-dead_strip

Usuń funkcje i dane, które są nieosiągalne dla punktu wejścia lub wyeksportowanych symboli.

-dead_strip_dylibs

Usuń dyliby niedostępne dla punktu wejścia lub wyeksportowanych symboli. Oznacza to, że pomija generowanie poleceń polecenia ładowania dla dylibs, które nie dostarczały żadnych symboli podczas połączenia. Ta opcja nie powinna być używana podczas łączenia z dylib, które jest wymagane w czasie wykonywania z jakiegoś pośredniego powodu, takiego jak dylib ma ważny inicjator.

I ta pomocna opcja

-why_live symbol_name

Rejestruje łańcuch odniesień do symbol_name. Dotyczy tylko z -dead_strip. Może pomóc w debugowaniu, dlaczego coś, co Twoim zdaniem powinno być usunięte, nie jest usuwane.

W man gcc / g ++ jest również uwaga, że ​​pewne rodzaje eliminacji martwego kodu są wykonywane tylko wtedy, gdy optymalizacja jest włączona podczas kompilacji.

Chociaż te opcje / warunki mogą nie odpowiadać Twojemu kompilatorowi, sugeruję, abyś poszukał czegoś podobnego w swoich dokumentach.

Mogą też pomóc nawyki programistyczne; np. dodaj staticdo funkcji, do których nie można uzyskać dostępu poza określonym plikiem; używaj krótszych nazw symboli (może trochę pomóc, prawdopodobnie nie za bardzo); używać w const char x[]miarę możliwości; ... ten artykuł , chociaż mówi o dynamicznych obiektach współdzielonych, może zawierać sugestie, których przestrzeganie może pomóc zmniejszyć ostateczny rozmiar wyjścia binarnego (jeśli celem jest ELF).

Odpowiedź jest -flto. Musisz przekazać to zarówno do kompilacji, jak i do kroków łączenia, w przeciwnym razie nic nie zrobi.

W rzeczywistości działa bardzo dobrze - zmniejszyłem rozmiar programu mikrokontrolera, który napisałem, do mniej niż 50% jego poprzedniego rozmiaru!

Niestety wydawało się to trochę wadliwe - miałem przypadki, gdy rzeczy nie były poprawnie budowane. Mogło to być spowodowane systemem kompilacji, którego używam (QBS; jest bardzo nowy), ale w każdym razie zalecałbym włączenie go tylko dla ostatecznej kompilacji, jeśli to możliwe, i dokładne przetestowanie tej kompilacji.

Chociaż nie chodzi tylko o symbole, jeśli chodzi o rozmiar - zawsze kompiluj z flagami -Osi -s. -Osoptymalizuje wynikowy kod pod kątem minimalnego rozmiaru pliku wykonywalnego i -susuwa tablicę symboli i informacje o relokacji z pliku wykonywalnego.

Czasami - jeśli pożądany jest mały rozmiar - zabawa z różnymi flagami optymalizacji może - lub nie - mieć znaczenie. Na przykład przełączanie -ffast-mathi / lub -fomit-frame-pointerczasami może zaoszczędzić nawet dziesiątki bajtów.

Wydaje mi się, że odpowiedź udzielona przez Nemo jest prawidłowa. Jeśli te instrukcje nie działają, problem może być związany z wersją gcc / ld, której używasz, jako ćwiczenie skompilowałem przykładowy program, korzystając z instrukcji opisanych tutaj

#include <stdio.h>
void deadcode() { printf("This is d dead codez\n"); }
int main(void) { printf("This is main\n"); return 0 ; }

Następnie skompilowałem kod przy użyciu coraz bardziej agresywnych przełączników usuwania martwego kodu:

gcc -Os test.c -o test.elf
gcc -Os -fdata-sections -ffunction-sections test.c -o test.elf -Wl,--gc-sections
gcc -Os -fdata-sections -ffunction-sections test.c -o test.elf -Wl,--gc-sections -Wl,--strip-all

Te parametry kompilacji i łączenia generowały pliki wykonywalne o rozmiarze, odpowiednio, 8457, 8164 i 6160 bajtów, co stanowiło największy wkład pochodzący z deklaracji „strip-all”. Jeśli nie możesz stworzyć podobnych redukcji na swojej platformie, być może Twoja wersja gcc nie obsługuje tej funkcjonalności. Używam gcc (4.5.2-8ubuntu4), ld (2.21.0.20110327) na Linux Mint 2.6.38-8-generic x86_64

strip --strip-unneededdziała tylko na tablicy symboli twojego pliku wykonywalnego. W rzeczywistości nie usuwa żadnego kodu wykonywalnego.

Biblioteki standardowe osiągają oczekiwany rezultat, dzieląc wszystkie swoje funkcje na osobne pliki obiektowe, które są łączone za pomocą ar. Jeśli następnie połączysz powstałe archiwum jako bibliotekę (tj. Dasz opcję -l your_libraryld), wtedy ld będzie zawierał tylko pliki obiektowe, a tym samym symbole, które są faktycznie używane.

Możesz również znaleźć niektóre odpowiedzi na to podobne pytanie dotyczące użytkowania.

Nie wiem, czy to pomoże w twojej obecnej sytuacji, ponieważ jest to nowa funkcja, ale możesz określić widoczność symboli w sposób globalny. Przekazywanie -fvisibility=hidden -fvisibility-inlines-hiddenpodczas kompilacji może pomóc konsolidatorowi w późniejszym pozbyciu się niepotrzebnych symboli. Jeśli tworzysz plik wykonywalny (w przeciwieństwie do biblioteki współdzielonej), nie ma nic więcej do zrobienia.

Więcej informacji (i szczegółowe podejście dla np. Bibliotek) jest dostępnych na wiki GCC .

Z podręcznika GCC 4.2.1, sekcja -fwhole-program:

Załóżmy, że bieżąca jednostka kompilacji reprezentuje cały kompilowany program. Wszystkie funkcje i zmienne publiczne, z wyjątkiem maintych połączonych przez atrybut, externally_visiblestają się funkcjami statycznymi iw efekcie są bardziej agresywnie optymalizowane przez optymalizatory międzyprocedurowe. Chociaż ta opcja jest równoważna z prawidłowym użyciem staticsłowa kluczowego dla programów składających się z pojedynczego pliku, w połączeniu z opcją --combineta flaga może być używana do kompilowania większości programów C o mniejszej skali, ponieważ funkcje i zmienne stają się lokalne dla całej połączonej jednostki kompilacji, a nie dla sam plik źródłowy.

Możesz użyć strip binarnego na pliku obiektowym (np. Wykonywalnym), aby usunąć z niego wszystkie symbole.

Uwaga: zmienia sam plik i nie tworzy kopii.