Я пытаюсь отладить написанную мной программу на C ++, но когда я запускаю ее в LLDB и останавливаю программу, она показывает мне только ассемблер, а не исходный код.
например после сбоя я пытаюсь отладить:
Process 86122 stopped
* thread #13: tid = 0x142181, 0x0000000100006ec1 debug_build`game::update() + 10961, stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
frame #0: 0x0000000100006ec1 debug_build`game::update() + 10961
debug_build`game::update:
-> 0x100006ec1 <+10961>: movq (%rdx), %rdx
0x100006ec4 <+10964>: movq %rax, -0xb28(%rbp)
0x100006ecb <+10971>: movq -0x1130(%rbp), %rax
0x100006ed2 <+10978>: movq 0x8(%rax), %rsi
Я собираю с -O0 -g
, Я вижу то же самое при запуске отладчика через XCode (я на OSX) или из командной строки.
Что еще мне нужно сделать, чтобы исходный код отображался в LLDB?
Дополнительные примечания
Вот пример типичной команды сборки:
clang++ -std=c++1y -stdlib=libc++ -fexceptions -I/usr/local/include -c -O2 -Wall -ferror-limit=5 -g -O0 -ftrapv lib/format.cpp -o format.o
Чем раньше -O2
я использую это по умолчанию, но я полагаю, что позже -O0
переопределяет это, верно?
Что я пробовал
Я воссоздал эту проблему с помощью простой программы «Hello World», использующей те же настройки сборки.
После некоторых поисков я попытался запустить dsymutil main.o
который сказал warning: no debug symbols in executable (-arch x86_64)
, так что, возможно, символы отладки не генерируются моими командами сборки?
Я также попытался добавить -gsplit-dwarf
к командам сборки, но без эффекта.
Вот команда ссылки из моей версии «Hello World»:
clang ++ main.o -L / usr / local / lib -g -o привет
Я побежал dwarfdump
(Я читал об этом здесь) на исполняемые и объектные файлы. Это выглядит на мой неподготовленный глаз как символы отладки являются присутствует в объектных файлах, но не в самом исполняемом файле (если dwarfdump
работает только с объектными файлами, что возможно). Так что, возможно, проблема связана с этапом связывания. Или, возможно, есть проблема с DWARF.
Теперь я получил эту работу в программе «Привет, мир», выполняя команды build один за другим в терминале. Поэтому я предполагаю, что это может быть проблемой с моей системой сборки (баба), возможно, запустив команды с другим рабочим каталогом, чтобы пути были искажены или что-то в этом роде.
Когда вы добавляете параметр командной строки -g в clang, отладочная информация DWARF помещается в .o
файл. Когда вы связываете свои объектные файлы (.o
, ranlib архивы ака статические библиотеки ака .a
файлы) в исполняемый файл / dylib / framework / bundle, «отладочные заметки» помещаются в исполняемый файл, чтобы сказать (1) расположение .o
файлы etc с информацией об отладке и (2) конечные адреса функций / переменных в исполняемом двоичном файле. Флаги оптимизации (-O0
, -O2
и т. д.) не влияют на генерацию отладочной информации — хотя отладочный код, скомпилированный с оптимизацией, намного сложнее, чем отладочный код, созданный в -O0
,
Если вы запускаете отладчик в этом исполняемом двоичном файле — без каких-либо других изменений — отладчик будет читать отладочную информацию из .o
и т.д. файлы до тех пор, пока они находятся в файловой системе по тому же пути к файлу, когда вы создали исполняемый файл. Это делает итеративную разработку быстрой — никакому инструменту не нужно читать, обновлять и выводить (большую) отладочную информацию. Вы можете увидеть эти «заметки отладки» в исполняемом файле, запустив nm -pa exename
и ищет OSO
записи (среди других). Это записи и работает strip(1)
на вашем исполняемом файле удалит их.
Если вы хотите собрать всю отладочную информацию (в .o
файлы) в автономный пакет, затем вы запускаете dsymutil
на исполняемый файл. Это использует примечания отладки (предположения: (1) .o
файлы по-прежнему находятся в исходном расположении, и (2) исполняемый файл не был удален) для создания «dSYM
расслоение «. Если бинарный exename, комплект dSYM exename.dSYM. Когда отладчик запущен exename, он будет смотреть рядом с этим двоичным файлом для пакета dSYM. Если он не найден, он выполнит поиск Spotlight, чтобы определить, находится ли dSYM в месте, указанном в центре внимания на вашем компьютере.
Вы можете запустить dwarfdump
на .o
файлы или в пакете dSYM — они оба содержат отладочную информацию. dwarfdump
не найдет никакой отладочной информации в вашем выходном исполняемом файле.
Итак, нормальный рабочий процесс: скомпилируйте с -g. Ссылка на исполняемый образ. Если итеративная разработка, запустите отладчик. Если вы отправляете / архивируете бинарный файл, создайте dSYM, удалите исполняемый файл.
Я решил это, добавив путь к символам отладки, которые присутствуют в каталоге a.out.dSYM, используя (lldb) target symbols add a.out.dSYM
команда.