Читать символы отладки, когда исходный файл был перемещен

Question

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

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

• сборочная машина проверяет источники /workspace/build/PROJECT/VERSION/dirs_with_sources
• строит локально с -g
• после создания копирует источники в /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, где поиск источника просто терпит неудачу. (И я предполагаю, что другие инструменты отладки, предназначенные для того, чтобы помочь мне перемещаться между исходным кодом и результатами сборки, столкнутся с похожими проблемами).

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

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

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

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

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

Answer 1

Комментарий @tom-tromey для gdb - это то, что работает для kcachegrind. В меню

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

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

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