Отладчик XCode не находит мои файлы

0

Я взял на себя довольно большой и сложный проект. Часть его представляет собой статическую (C++) библиотеку, которая создается файлом Xcode (который, по-моему, был создан CMake, я считаю...)

Само приложение находится в совершенно другом проекте.

Когда я отлаживаю приложение и хочу войти в библиотеку, отображается только сборка. Символы все, кажется, есть, заметно вывод начинается с MyApp'Foo::bar(char const*) at Foo.cpp:102: и я вижу такие вещи, как 0x1507a6: bl 0x150838; Foo::fazbar(int) at Foo.cpp:206 0x1507a6: bl 0x150838; Foo::fazbar(int) at Foo.cpp:206

Это, для меня, говорит, что символизация существует и фактически работает.

Теперь Foo.cpp находится на моей машине. Я могу открыть этот файл, и действительно, на строке 206 вызывается Foo :: fazbar.

Выходные данные nm и otool также не выглядят подозрительными.

Почему lldb (отладчик Xcode) не находит мой файл? Как я могу указать lldb, где находятся файлы?

Любые указатели оцениваются.

  • 0
    Используя поиск изображений lldb --address --verbose, я вижу, что «Module: file» правильный, но «CompileUnit:» находится по совершенно неверному адресу. Я буду исследовать
  • 1
    Отладочная информация существует в двух местах в Mac OS X: в объектном файле (файлы .o ) и в пакетах dSYM ( .dSYM ). Когда вы компилируете и тестируете программу, Xcode обычно просто оставляет отладочную информацию в файлах .o . Когда приходит время .dSYM двоичный файл, обычно создается файл .dSYM , который помещает всю информацию отладки в одно место. Статическая библиотека (архив ranlib) представляет собой набор файлов .o . В двоичном файле, который ссылается на .a lib, будет скопирована вся использованная отладочная информация в его .dSYM . Итак - ищите .dSYM . И попробуйте расширить .a lib ( ar x libname.a и поискать в .o файлах с помощью dwarfdump .
Теги:
xcode
lldb
mach-o

1 ответ

1
Лучший ответ

Вы перемещали исходные файлы по сравнению с тем, когда была построена библиотека?

Поделиться
  • 0
    Нет, код остался там же, где и был. На самом деле, двоичный файл библиотеки остался там же, где и был, и был связан с тем, где он был построен.
  • 0
    Проблема заключалась в том, что неправильный двоичный файл был связан! Это содержало пути к источнику на чужой машине. Помещение в правильный двоичный файл решило проблему…

Ещё вопросы

Сообщество Overcoder
Наверх
Меню