Как заставить LLDB распечатать расположение общих библиотек в памяти?
Я пытаюсь собрать как можно больше информации о явной проблеме бесконечного цикла, замеченной при использовании Valgrind 3.11.0 в Mac OS 10.11.1 "El Capitan".
Когда я бегу valgrind в моей программе в LLDB или прикрепить к valgrind Запустив мою программу и затем остановив процесс, я получаю обратную трассировку, как показано ниже:
* поток #1: tid = 0x24ab4, 0x000000010805920b, причина остановки = сигнал SIGSTOP
* кадр № 0: 0x000000010805920b
кадр № 1: 0x0000000108040dda
кадр № 2: 0x00000001080b6790
кадр № 3: 0x00000001080b2fd3
кадр № 4: 0x00000001080b7c25
кадр № 5: 0x00000001080b6113
кадр № 6: 0x00000001080b3cd0
кадр № 7: 0x00000001080c54d9
Как мне узнать, какому объекту (-ам) соответствуют эти кадры?
Я старался vmmap в процессе, но он не показывает никакой информации. В частности, раздел "Незаписываемые области для процесса", в котором обычно бы отображались диапазоны адресов, в которые dllibs были сопоставлены с памятью процесса, пуст:
$ vmmap -v 21729
Процесс: memcheck-amd64-darwin [21729]
Путь: /usr/local/Cellar/valgrind/3.11.0/lib/valgrind/memcheck-amd64-darwin
Адрес загрузки: 0x100000000
Идентификатор: memcheck-amd64-darwin
Версия:???
Тип кода: X86-64
Родительский процесс: bash [11895]
Дата / Время: 2015-11-30 11:52:16.392 -0500
Время запуска: 2015-11-30 11:51:53.557 -0500
Версия ОС: Mac OS X 10.11.1 (15B42)
Версия отчета: 7
Инструмент анализа: /Applications/Xcode.app/Contents/Developer/usr/bin/vmmap
Версия инструмента анализа: Xcode 7.1.1 (7B1005)
----
Карта виртуальной памяти процесса 21729 (memcheck-amd64-darwin)
Формат выходного отчета: 2,4 - 64-битный процесс
Размер страницы виртуальной машины: 4096 байт
==== Незаписываемые области для процесса 21729
РЕГИОН ТИПА СТАРТ - КОНЕЦ [ VSIZE RSDNT DIRTY SWAP] PRT/MAX SHRMOD PURGE РЕГИОН РЕГИОНА
==== Доступные для записи регионы для процесса 21729
РЕГИОН ТИПА СТАРТ - КОНЕЦ [ VSIZE RSDNT DIRTY SWAP] PRT/MAX SHRMOD PURGE РЕГИОН РЕГИОНА
==== Легенда
SM= режим совместного использования:
COW=copy_on_write PRV= частный NUL= пустой ALI= псевдоним
SHM= общий ZER= заполненный нулями S/A=shared_alias
PURGE= режим очистки:
V= летучий N= энергонезависимый E = пустой, в противном случае не очищается
==== Сводка по процессу 21729
(ноль)
2 ответа
(lldb) image lookup -va <ADDRESS>
покажет кучу информации о данном адресе, и:
(lldb) image list
перечислит все библиотеки, и
(lldb) image dump sections
выведет подробную информацию о расположении разделов всех загруженных библиотек.
Однако, если бы lldb смог выяснить, какая библиотека была отображена по заданному адресу при печати кадра, он показал бы это (если вы не изменили настройку формата кадра.) Таким образом, эти команды могут не показать вам намного больше или.
Обратите внимание, что valgrind делает странные вещи с выполнением вашей программы, чтобы творить ее магию, и я не удивлюсь, если внешние инструменты, такие как lldb & vmmap, не смогут увидеть основную правду.
Поскольку у вас есть недавняя ОС и инструменты, вы можете попробовать ASAN от llvm вместо valgrind, и посмотреть, поймет ли он вашу проблему. ASAN требует перестройки, но из-за статических уловок среда выполнения выглядит нормально для других инструментов.
Прошло много времени с тех пор, как я использовал valgrind, я полностью забыл, как отладка работала с ним...
Чтобы отладить программу, работающую под valgrind, вы должны указать valgrind открыть порт gdbserver для отладчика, с которым можно общаться. Valgrind знает, как отменить все его волшебство, и притворяется, что программа, которой он управляет, - просто обычная программа...
Это описано в разделе 3.2 в:
http://valgrind.org/docs/manual/manual-core-adv.html.
LLDB также знает, как разговаривать, используя удаленный протокол GDB, и имеет команду gdb-remote подключиться к серверу.
Это не работает с lldb прямо из коробки, кажется, есть некоторая проблема с определениями регистра. Похоже, что в valgrind есть работа по ее улучшению:
https://bugs.kde.org/show_bug.cgi?id=356174
Но так или иначе, это то, как это должно работать.