LLDB не показывает исходный код

Я пытаюсь отладить написанную мной программу на 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 переопределяет это, верно?

Что я пробовал

  1. Я воссоздал эту проблему с помощью простой программы «Hello World», использующей те же настройки сборки.

  2. После некоторых поисков я попытался запустить dsymutil main.o который сказал warning: no debug symbols in executable (-arch x86_64), так что, возможно, символы отладки не генерируются моими командами сборки?

  3. Я также попытался добавить -gsplit-dwarf к командам сборки, но без эффекта.

  4. Вот команда ссылки из моей версии «Hello World»:

    clang ++ main.o -L / usr / local / lib -g -o привет

  5. Я побежал dwarfdump (Я читал об этом здесь) на исполняемые и объектные файлы. Это выглядит на мой неподготовленный глаз как символы отладки являются присутствует в объектных файлах, но не в самом исполняемом файле (если dwarfdump работает только с объектными файлами, что возможно). Так что, возможно, проблема связана с этапом связывания. Или, возможно, есть проблема с DWARF.

  6. Теперь я получил эту работу в программе «Привет, мир», выполняя команды build один за другим в терминале. Поэтому я предполагаю, что это может быть проблемой с моей системой сборки (баба), возможно, запустив команды с другим рабочим каталогом, чтобы пути были искажены или что-то в этом роде.

15

Решение

Когда вы добавляете параметр командной строки -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, удалите исполняемый файл.

15

Другие решения

Я решил это, добавив путь к символам отладки, которые присутствуют в каталоге a.out.dSYM, используя (lldb) target symbols add a.out.dSYM команда.

3

По вопросам рекламы [email protected]