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

Я пытаюсь отлаживать программу C++, которую я пишу, но когда я запускаю ее в LLDB и останавливаю программу, она показывает мне только ассемблер, а не исходный источник. например, после аварии Im пытается отладить:

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 (Im on 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 существует, потому что это используется по умолчанию Im, но я полагаю, что более поздний -O0 переопределяет его, не так ли?

Что я пытался

  1. Ive воссоздал эту проблему с помощью простой "привет мировой программы", используя те же настройки сборки.

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

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

  4. Вот ссылка из моей 'hello world version:

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

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

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

Ответ 1

Когда вы добавляете параметр командной строки -g для clang, информация об отладке DWARF помещается в файл .o. Когда вы связываете свои объектные файлы (.o, ranlib archives aka static libraries aka .a files) в исполняемый файл /dylib/framework/bundle, в исполняемый файл помещаются "отладочные заметки", чтобы сказать (1) местоположение .o etc файлы с информацией отладки и (2) окончательные адреса функций/переменных в исполняемом двоичном файле. Флаги оптимизации (-O0, -O2 т.д.) Не влияют на генерацию отладочной информации - хотя отладочный код, скомпилированный с оптимизацией, намного сложнее, чем отладочный код, построенный на -O0.

Если вы запустите отладчик в исполняемом двоичном файле - без каких-либо других изменений - отладчик будет считывать информацию об отладке из файлов .o т.д., Пока они все еще находятся в файловой системе на том же пути к файлу, когда вы создаете исполняемый файл, Это ускоряет итеративную разработку - никому не нужно читать, обновлять и выводить (большую) информацию об отладке. Вы можете увидеть эти "отладочные заметки" в исполняемом файле, выполнив nm -pa exename и ищет записи OSO (среди прочих). Это записи nlist stabs, а беговая strip(1) в вашем исполняемом файле удалит их.

Если вы хотите собрать всю информацию об отладке (в файлах .o) в автономный пакет, тогда вы запустите dsymutil в исполняемом файле. Это использует отладочные примечания (предположения: (1) файлы .o все еще находятся в исходном местоположении и (2) исполняемый файл не был удален), чтобы создать "пакет dSYM ". Если двоичный файл является exename, пакет dSYM имеет exename.dSYM. Когда отладчик запускается на exename, он будет выглядеть рядом с этим двоичным кодом для пакета dSYM. Если он не найден, он будет выполнять поиск Spotlight, чтобы узнать, находится ли dSYM в индексированном месте на вашем компьютере.

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

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

Ответ 2

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