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

Question

Я пытаюсь отладить написанную мной программу на 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 один за другим в терминале. Поэтому я предполагаю, что это может быть проблемой в моей системе сборки ( Tup), возможно, при запуске команд с другим рабочим каталогом, чтобы пути были искажены или что-то в этом роде.

Answer 1

Когда вы добавляете параметр командной строки -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 bundle ". Если бинарный файл - exename, то dSYM-пакет - exename.dSYM. Когда отладчик запускается по exename, он будет искать рядом с этим бинарным файлом dSYM-пакет. Если он там не найден, он выполнит поиск Spotlight, чтобы увидеть если dSYM находится в месте, указанном в центре внимания на вашем компьютере.

Вы можете запустить dwarfdump на .o файлы или в пакете dSYM - они оба содержат отладочную информацию. dwarfdump не найдет никакой отладочной информации в вашем выходном исполняемом файле.

Итак, нормальный рабочий процесс: скомпилируйте с -g. Ссылка на исполняемый образ. Если итеративная разработка, запустите отладчик. Если вы отправляете / архивируете бинарный файл, создайте dSYM, удалите исполняемый файл.

Answer 2

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