Использование GCC для поиска недоступных функций (мертвый код)

Я искал способ найти статически недоступные функции в (очень) большом проекте на C ++. Я пробовал использовать doxygen и другие предлагаемые здесь инструменты статического анализа, но мне показалось, что проект слишком сложен для них. В конце концов я решил, что использование инструментов GCC (g ++, gprof, gcov и т. Д.) - самый безопасный вариант, хотя я не мог понять, как это сделать.

Я думаю, что оптимизации g ++ устраняют статически недоступные функции, но я не уверен, как получить имена функций, которые он устраняет.

У Вас есть какие-то предложения?


gcc c++ dead-code
person stnr    schedule 16.11.2010    source источник
comment
stackoverflow.com/questions/229069 /   -  person Veger    schedule 16.11.2010

Ответы (2)


arrow_upward
8
arrow_downward

Оптимизация мертвого кода обычно выполняется компоновщиком - компилятор не имеет обзора. Однако компилятор мог исключить неиспользуемые static функции (поскольку они имеют внутреннюю связь).

Следовательно, вам следует смотреть не на параметры GCC, а на параметры ld. Кажется, ты хочешь --print-gc-sections. Однако обратите внимание, что вы, вероятно, хотите, чтобы GCC поместил каждую функцию в отдельный раздел -ffunction-sections. По умолчанию GCC помещает все функции в один и тот же раздел, а ld недостаточно умен, чтобы исключить неиспользуемые функции - он может удалить только неиспользуемые разделы.

person MSalters    schedule 16.11.2010
comment
Параметр --print-gc-sections выводит результат следующим образом: Removing unused section '.text._DriverUnloadHandler' in file '/tmp/ccLoxO8q.ltrans0.ltrans.o'. Итак, как найти исходное имя файла C? - person smwikipedia; 17.08.2018
comment
И -ffunction-sections не работает с кодом сборки, так как не требует компиляции. Таким образом, все функции в ассемблерном коде будут находиться в разделе .text, что делает --print-gc-sections менее полезным для обнаружения неиспользуемых функций. - person smwikipedia; 17.08.2018
comment
@smwikipedia: проверьте objdump -W /tmp/ccLoxO8q.ltrans0.ltrans.o - person MSalters; 17.08.2018
comment
@smwikipedia: Что касается сборки, ее можно структурировать способами, которые нельзя выразить как функции. Например, вы не можете вызвать середину функции C; Функции C имеют единую точку входа. Сборка - это просто последовательность инструкций, и вы можете перейти к любой точке этой последовательности. В x86 нет даже ограничения на переход к фактической границе инструкции! - person MSalters; 17.08.2018
comment
да. Я согласен с тобой. Так что эти параметры полезны только для C. Но этого достаточно для большинства сценариев. Спасибо. - person smwikipedia; 17.08.2018
comment
@smwikipedia: Конечно, вы можете использовать .segment .text.MyAssemblyFoo для создания разделов в вашей сборке вручную. Это обоюдоострый характер сборки: все можно делать вручную, и все приходится делать вручную. - person MSalters; 17.08.2018

arrow_upward
-1
arrow_downward

gcov - это то, что вы ищете. У вас есть то, что указано в вопросе, вы не смотрели на это?

person Andrew Sledge    schedule 16.11.2010
comment
Не совсем, gcov создает файл журнала с именем sourcefile.gcov, который указывает, сколько раз выполнялась каждая строка исходного файла sourcefile.c. Это динамический анализ, а не статический. - person stnr; 16.11.2010