Как заставить профилировщики (valgrind, perf, pprof) подобрать / использовать локальную версию библиотеки с символами отладки при использовании mpirun? - PullRequest
4 голосов
/ 09 июля 2011

Редактировать: добавлено важное замечание о том, что речь идет об отладке приложения MPI

В установленной системе общей библиотеке нет символов отладки:

$ readelf -S /usr/lib64/libfftw3.so | grep debug
$

Поэтому я скомпилировал и установил в свой домашний каталог свою собственную версию с включенной отладкой (--with-debug CFLAGS=-g):

$ $ readelf -S ~/lib64/libfftw3.so | grep debug
  [26] .debug_aranges    PROGBITS         0000000000000000  001d3902
  [27] .debug_pubnames   PROGBITS         0000000000000000  001d8552
  [28] .debug_info       PROGBITS         0000000000000000  001ddebd
  [29] .debug_abbrev     PROGBITS         0000000000000000  003e221c
  [30] .debug_line       PROGBITS         0000000000000000  00414306
  [31] .debug_str        PROGBITS         0000000000000000  0044aa23
  [32] .debug_loc        PROGBITS         0000000000000000  004514de
  [33] .debug_ranges     PROGBITS         0000000000000000  0046bc82

Я установил как LD_LIBRARY_PATH, так и LD_RUN_PATH для включения ~/lib64 в первую очередь, иldd program подтверждает, что должна использоваться локальная версия библиотеки:

$ ldd a.out | grep fftw
        libfftw3.so.3 => /home/narebski/lib64/libfftw3.so.3 (0x00007f2ed9a98000)

Рассматриваемая программа параллельная численное приложение с использованием MPI (интерфейс передачи сообщений).Поэтому для запуска этого приложения необходимо использовать оболочку mpirun (например, mpirun -np 1 valgrind --tool=callgrind ./a.out).Я использую реализацию OpenMPI.

Тем не менее, различные профилировщики: callgrind инструмент в Valgrind , Профилирование процессора google-perfutils и perf не находит эти символы отладки, что приводит к более или менее бесполезным выходным данным:

  • calgrind:

    $ callgrind_annotate --include=~/prog/src --inclusive=no  --tree=none
    [...]
    --------------------------------------------------------------------------------
                Ir  file:function
    --------------------------------------------------------------------------------
    32,765,904,336  ???:0x000000000014e500 [/usr/lib64/libfftw3.so.3.2.4]
    31,342,886,912  /home/narebski/prog/src/nonlinearity.F90:__nonlinearity_MOD_calc_nonlinearity_kxky [/home/narebski/prog/bin/a.out]
    30,288,261,120  /home/narebski/gene11/src/axpy.F90:__axpy_MOD_axpy_ij [/home/narebski/prog/bin/a.out]
    23,429,390,736  ???:0x00000000000fc5e0 [/usr/lib64/libfftw3.so.3.2.4]
    17,851,018,186  ???:0x00000000000fdb80 [/usr/lib64/libmpi.so.1.0.1]
    
  • google-perftools:

    $ pprof --text a.out prog.prof
    Total: 8401 samples
         842  10.0%  10.0%      842  10.0% 00007f200522d5f0
         619   7.4%  17.4%     5025  59.8% calc_nonlinearity_kxky
         517   6.2%  23.5%      517   6.2% axpy_ij
         427   5.1%  28.6%     3156  37.6% nl_to_direct_xy
         307   3.7%  32.3%     1234  14.7% nl_to_fourier_xy_1d
    
  • perf events:

    $ perf report --sort comm,dso,symbol
    # Events: 80K cycles
    #
    # Overhead  Command         Shared Object                                        Symbol
    # ........  .......  ....................  ............................................
    #
        32.42%  a.out     libfftw3.so.3.2.4     [.]            fdc4c
        16.25%  a.out             7fddcd97bb22  [.]     7fddcd97bb22
         7.51%  a.out     libatlas.so.0.0.0     [.] ATL_dcopy_xp1yp1aXbX
         6.98%  a.out     a.out                 [.] __nonlinearity_MOD_calc_nonlinearity_kxky
         5.82%  a.out     a.out                 [.] __axpy_MOD_axpy_ij
    

Редактировать Добавлено 11.07.2011 :Я не знаю, важно ли это, но:

$ file /usr/lib64/libfftw3.so.3.2.4
/usr/lib64/libfftw3.so.3.2.4: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped

и

$ file ~/lib64/libfftw3.so.3.2.4
/home/narebski/lib64/libfftw3.so.3.2.4: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, not stripped

Ответы [ 3 ]

2 голосов
/ 11 июля 2011

Если /usr/lib64/libfftw3.so.3.2.4 указано в выводе callgrind, то ваш LD_LIBRARY_PATH=~/lib64 не имел никакого эффекта .

Попробуйте еще раз с export LD_LIBRARY_PATH=$HOME/lib64.Также следите за любыми сценариями оболочки, которые вы вызываете, что может привести к перезагрузке вашей среды.

1 голос
/ 15 июля 2011

Вы и Занятый Русский почти наверняка правы; скрипт mpirun все портит. Два варианта:

Большинство реализаций x86 MPI, на практике, относятся только к запуску исполняемого файла

./a.out

так же, как

mpirun -np 1 ./a.out.

Им не обязательно делать это, но OpenMPI, безусловно, делает, как и MPICH2 и IntelMPI. Так что, если вы можете выполнять отладку поочередно, вы должны просто иметь возможность

valgrind --tool=callgrind ./a.out.

Однако, если вы хотите запустить mpirun, возможно, проблема в том, что ваш ~/.bashrc (или что-то еще) поступает, отменяя ваши изменения в LD_LIBRARY_PATH и т. д. Самый простой - просто временно поместить измененные переменные среды в ~/.bashrc на время выполнения.

1 голос
/ 09 июля 2011

Способ, которым последние инструменты профилирования обычно справляются с этой ситуацией, заключается в обращении к внешней, совпадающей, неснятой версии библиотеки.

В дистрибутивах Linux на основе Debian это обычно делается путем установки версии пакета с суффиксом -dbg;на основе Redhat они называются -debuginfo.

В случае инструментов, которые вы упомянули выше;обычно они просто работают (tm) и находят символы отладки для библиотеки, если пакет отладочной информации был установлен в стандартном месте.

...