Как узнать, какие функции вызываются в многопроцессорной программе без изменения исходного кода?

Я работаю над проектом, в котором мне нужно найти, какие функции вызываются в различных программах Linux (написанных на C) при определенных входных данных. Мой текущий подход заключался в том, чтобы скомпилировать программу с -pg (опция профилирования), запустить ее и найти, какие функции вызываются при обработке вывода gprof. В выходном файле отображаются только функции, которые вызываются хотя бы один раз.

Очевидная проблема заключается в том, что только один процесс может записывать в выходной файл gprof. Если программа разветвляет несколько процессов, я не получаю результатов профилирования от других процессов.

Есть ли способ заставить gprof создавать выходной файл для каждого процесса (может быть, помечен pid)? В руководстве предлагается изменить каждый процесс в другой каталог, но я не хочу изменять исходный код для этого. Есть ли другой инструмент для Linux, который может помочь?


c linux code-coverage profiling gprof
person Jay Conrod    schedule 28.04.2009    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Взгляните на GCov: http://gcc.gnu.org/onlinedocs/gcc/Gcov.html

person Dimitri Tcaciuc    schedule 28.04.2009
comment
У gcov точно такая же проблема. О покрытии дочернего процесса не сообщается. - person deft_code; 10.06.2010

arrow_upward
3
arrow_downward

Здесь они предлагают использовать tprof:

Вы пробовали валгринд?

http://www.network-theory.co.uk/docs/valgrind/valgrind_17.html

--child-silent-after-fork=<yes|no> [default: no]

Если этот параметр включен, Valgrind не будет показывать какие-либо отладочные или журналируемые данные для дочернего процесса, полученные в результате вызова fork. Это может сделать вывод менее запутанным (хотя и более вводящим в заблуждение) при работе с процессами, которые создают потомков. Это особенно полезно в сочетании с --trace-children =. Использование этого флага также настоятельно рекомендуется, если вы запрашиваете вывод XML (--xml = yes), поскольку в противном случае XML из дочернего и родительского элементов может смешаться, что обычно делает его бесполезным.

person Tom    schedule 28.04.2009