Як видалити невикористані символи C / C ++ за допомогою GCC та ld?

Мені потрібно жорстко оптимізувати розмір мого виконуваного файлу ( ARMрозробка), і я помітив, що в моїй поточній схемі збірки ( gcc+ ld) невикористані символи не знімаються.

Використання arm-strip --strip-unneededдля отриманих виконуваних файлів / бібліотек не змінює розмір виводу виконуваного файлу (я не маю поняття, чому, можливо, він просто не може) .

Яким би був спосіб (якщо він існує) змінити мій конвеєр будівлі, щоб невикористані символи були вилучені з отриманого файлу?

Я б навіть не думати про це, але моєї поточної впроваджений середовище не дуже «сильна» і збереженні навіть 500Kз 2Mрезультатів в дуже хорошому прирості продуктивності завантаження.

Оновлення:

На жаль, поточна gccверсія, яку я використовую, не має цього -dead-stripваріанту, а -ffunction-sections... + --gc-sectionsfor ldне дає суттєвої різниці для отриманого результату.

Я вражений тим, що це навіть стало проблемою, тому що я був впевнений, що він gcc + ldповинен автоматично знімати невикористані символи (чому вони взагалі повинні їх зберігати?).

Для GCC це здійснюється у два етапи:

Спочатку зберіть дані, але скажіть компілятору розділити код на окремі розділи в блоці перекладу. Це буде зроблено для функцій, класів та зовнішніх змінних за допомогою наступних двох прапорів компілятора:

-fdata-sections -ffunction-sections

Зв’яжіть одиниці перекладу разом, використовуючи прапор оптимізації лінкера (це призводить до того, що лінкер відкидає нерозділені розділи):

-Wl,--gc-sections

Отже, якщо у вас був один файл під назвою test.cpp, у якому були задекларовані дві функції, але одна з них була невикористаною, ви можете опустити невикористаний, виконавши наступну команду gcc (g ++):

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

(Зауважте, -Os - це додатковий прапор компілятора, який повідомляє GCC оптимізувати для розміру)

Якщо вірити цьому потоку , вам потрібно поставити -ffunction-sectionsі-fdata-sections до gcc, який помістить кожну функцію та об’єкт даних у свій розділ. Потім ви даєте і --gc-sectionsGNU ld для видалення невикористаних секцій.

Ви хочете перевірити свої документи на свою версію gcc & ld:

Однак для мене (OS X gcc 4.0.1) я знаходжу їх для ld

-dead_strip

Видаліть функції та дані, які недоступні для точки входу чи експортованих символів.

-dead_strip_dylibs

Видаліть діліб, який недоступний для точки входу або експортованих символів. Тобто, пригнічує генерацію команд завантаження команд для dylibs, які не надавали символів під час посилання. Цю опцію не слід застосовувати під час посилання на диліб, який необхідний під час виконання з певної непрямої причини, наприклад, що диліб має важливий ініціалізатор.

І це корисний варіант

-why_live symbol_name

Журнали ланцюга посилань на ім'я символу. Застосовується лише з -dead_strip. Це може допомогти налагодити, чому те, що, на вашу думку, повинно бути мертвою смугою, не видаляється.

У людині gcc / g ++ є також примітка, що певні види усунення мертвих кодів виконуються лише в тому випадку, якщо під час компіляції включена оптимізація.

Хоча ці параметри / умови можуть не відповідати вашому компілятору, я пропоную вам знайти щось подібне у своїх документах.

Звички програмування теж можуть допомогти; наприклад, додати staticдо функцій, до яких немає доступу за межами певного файлу; використовувати короткі назви символів (може допомогти трохи, швидше за все, не надто); використовувати const char x[]де можливо; ... цей документ , хоч і говорить про динамічні спільні об'єкти, може містити пропозиції, які, якщо дотримуватися, можуть допомогти зменшити розмір остаточного бінарного виводу (якщо ваша мета - ELF).

Відповідь така -flto. Ви повинні передати його як до компіляції, так і до посилань, інакше це нічого не робить.

Насправді це працює дуже добре - зменшив розмір програми мікроконтролера, яку я написав, менше ніж на 50% від її попереднього розміру!

На жаль, це здавалося трохи баггі - у мене були випадки, коли речі будуються неправильно. Можливо, це було пов’язано із системою збірки, яку я використовую (QBS; це дуже нова), але в будь-якому випадку я рекомендую вам увімкнути її лише для остаточної збірки, якщо це можливо, і протестувати її.

Хоча не строго щодо символів, якщо ви хочете за розміром - завжди компілюйте -Osі -sпрапори. -Osоптимізує отриманий код для мінімального розміру виконуваного файлу та -sвидаляє таблицю символів та інформацію про переміщення із виконуваного файлу.

Іноді - якщо бажано невеликого розміру - розігрування з різними прапорами оптимізації може мати або не може мати значення. Наприклад, перемикання -ffast-mathта / або часом -fomit-frame-pointerможе заощадити навіть десятки байтів.

Мені здається, що відповідь, яку надав Немо, є правильною. Якщо ці інструкції не працюють, проблема може бути пов’язана з версією gcc / ld, яку ви використовуєте, як вправу я склав приклад програми, використовуючи тут інструкції, детальні

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

Потім я скомпілював код за допомогою прогресивно більш агресивних комутаторів видалення мертвого коду:

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

Ці параметри компіляції та зв'язування давали виконувані файли розміром 8457, 8164 та 6160 байт відповідно, найбільш суттєвий внесок, що надходить з декларації "смуга всіх". Якщо ви не можете створити подібні скорочення на своїй платформі, можливо, ваша версія gcc не підтримує цю функціональність. Я використовую gcc (4.5.2-8ubuntu4), ld (2.21.0.20110327) на Linux Mint 2.6.38-8-generic x86_64

strip --strip-unneededпрацює лише в таблиці символів вашого виконуваного файлу. Він фактично не видаляє будь-який виконуваний код.

Стандартні бібліотеки досягають результату, якого ви шукаєте, розділяючи всі їх функції на окремі об’єктні файли, які поєднуються за допомогою ar. Якщо потім зв’язати отриманий архів як бібліотеку (тобто дати опцію-l your_library ld), то ld буде містити лише об'єктні файли, а отже, і символи, які фактично використовуються.

Ви також можете знайти деякі відповіді на подібне питання використання.

Я не знаю, чи це допоможе у вашому поточному становищі, оскільки це нещодавня особливість, але ви можете визначити видимість символів у глобальному масштабі. Проходження -fvisibility=hidden -fvisibility-inlines-hiddenпри компіляції може допомогти лінкеру згодом позбутися від зайвих символів. Якщо ви створюєте виконуваний файл (на відміну від спільної бібліотеки) більше нічого робити.

Більше інформації (та тонкодослідного підходу, наприклад, для бібліотек) доступно на вікі GCC .

З посібника GCC 4.2.1, розділ -fwhole-program:

Припустимо, що поточний блок компіляції представляє всю програму, яка складається. Усі загальнодоступні функції та змінні, за винятком mainта об'єднаних за атрибутом, externally_visibleстають статичними функціями, а вплив впливає на більш агресивну оптимізацію міжпроцедурними оптимізаторами. Хоча ця опція еквівалентна правильному використанню staticключового слова для програм, що складаються з одного файлу, у поєднанні з опцією --combineцей прапор може використовуватися для компіляції більшості менших масштабних програм C, оскільки функції та змінні стають локальними для всього комбінованого блоку компіляції, а не для сам файл-джерело.

Ви можете використати смужку двійкових файлів на об’єктному файлі (наприклад, виконуваний файл), щоб зняти з нього всі символи.

Примітка: він змінює сам файл і не створює копію.