читать символы отладки, когда исходный файл был перемещен - PullRequest
0 голосов
/ 23 мая 2018

При использовании kcachegrind или просто objdump -C -l -d somelib.so я заметил, что некоторая отладочная информация в моих общих библиотеках не актуальна из-за процесса копирования из локальной файловой системы компьютера сборки в общую сетевую файловую систему установки.

Рабочий процесс:

  • машина сборки проверяет источники для /workspace/build/PROJECT/VERSION/dirs_with_sources
  • локальных сборок с -g
  • послеbuild копирует исходники в /software/PROJECT/VERSION/dirs_with_sources, а встроенные общие библиотеки в /software/PROJECT/VERSION/InstallArea/ARCHITECTURE/lib

Когда я сейчас открываю общие библиотеки с помощью objdump -C -l -d somelib.so, я вижу символы отладки, такие как:

0000000000001a89 <_GLOBAL__sub_I_somesource.cpp>:
_GLOBAL__sub_I_somesource.cpp():
/workspace/build/PROJECT/VERSION/subdir/subsubdir/src/somesource.cpp:33
    1a89: 48 83 ec 08           sub    $0x8,%rsp
    1a8d: be ff ff 00 00        mov    $0xffff,%esi
    1a92: bf 01 00 00 00        mov    $0x1,%edi
    1a97: e8 a4 fb ff ff        callq  1640 <__static_initialization_and_destruction_0(int, int)>
    1a9c: 48 83 c4 08           add    $0x8,%rsp
    1aa0: c3                    retq

Имя файла здесь не может быть просто скопировано и вставлено, так как у меня нет смонтированного каталога на моем компьютере пользователя, и мне нужно заменить /workspace/build на software.

Это достаточно раздражает, но резко терпит неудачупри запуске, например, kcachegrind, где поиск источника просто не удается.(И я предполагаю, что другие инструменты отладки, предназначенные для того, чтобы помочь мне перемещаться между исходным кодом и результатами сборки, столкнутся с похожими проблемами).

Существует ли общий способ работы с символами отладки перемещаемых файлов?Я предполагаю, что это всегда должно быть проблемой при отправке двоичной версии библиотеки с символами отладки.

РЕДАКТИРОВАТЬ:

То, что я использовал в качестве обходного пути и хотел бы избежать в качестве общего решения:

  • mount /software в /workspace/build: пользователь (kcachegrind) может не иметь прав для создания /workspace

  • перекомпиляции из источникаиметь фиксированную отладочную информацию: для этого может потребоваться больше времени компиляции (и, возможно, пользовательского диска), чем пользователь желает инвестировать (отчасти поэтому у нас есть машина для сборки и сетевая установка в первую очередь).

1 Ответ

0 голосов
/ 28 мая 2018

@ Комментарий Тома-Тромея для gdb также работает для kcachegrind.В меню

Настройки → Настроить KCachegrind → Аннотации → Добавить

Можно добавить дополнительные пути поиска, поэтому для указания источников достаточно указать /software/.Я еще не проверял, что происходит, если в пути поиска существуют похожие источники (в исходном примере несколько версий одного и того же исходного файла существуют в каталогах с разными версиями), но на практике поиск из /software/ все равно слишком медленный (слишкоммного подкаталогов для поиска).По этой причине я сейчас использую /software/PROJECT/VERSION/dirs_with_sources в этом меню.

Из того, как я понимаю документы, этот путь поиска kcachegrind не делает то же самое, что substitue-path в gdb (что, вероятно, лучше подойдет впример здесь).

...