"Нет исходного файла с именем" отладка ошибок "Eclipse CDT

У меня есть проект с общей библиотекой (динамически загружается), и я пытаюсь его отладить. Появляется следующее сообщение об ошибке:

No source file named /home/username/Code/path/to/project/MyFile.cpp.

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

Кто-нибудь знает, что с этим делать?

Ответ 1

Я столкнулся с одной проблемой, хотя мои точки останова были в самом исполняемом файле, а не в общей библиотеке. Чтобы решить эту проблему, мне пришлось открыть "Конфигурация отладки", выбрать конфигурацию отладки и настроить следующие параметры:

Внизу есть ссылка "Выбрать другое...", чтобы выбрать "Создать процесс". Нажмите на ссылку. Отметьте "Использовать настройки конфигурации". Выберите "Стандартный запуск процесса запуска" и нажмите "ОК".
Перейдите на вкладку "Отладчик" и в верхней части вкладки выберите "Отладчик: gdb/mi" . Что может/не может иметь значения: на той же вкладке есть также флажок "Использовать полный путь к файлу для установки контрольных точек" - я играл с этим, но он, похоже, не влияет на проблему, которую мы наблюдаем (очевидно, наши исходные пути уже полные пути).

Для точек останова в разделяемых библиотеках вам может понадобиться дополнительная информация (особенно о отложенных контрольных точках) из Отладка с eclipse cdt и gdb и Почему eclipse cdt игнорирует точки останова.

Примечание. Это относится к Eclipse Kepler (4.3) и gdb 7.4.

Ответ 2

У меня была такая же проблема, но в моем случае это была моя ошибка. Некоторые из моих проектов были настроены на Release Configuration, и отладчик, естественно, не смог найти информацию о исходном файле.

Ответ 3

У меня была та же проблема. Я не мог установить точку останова в файле общей библиотеки (.so), скомпилированном в другом месте, чем моя программа. Чтобы исправить это:

Перейдите на вкладку "Конфигурация отладки", вкладка "Источник"
Добавить каталог компиляции (я использовал расположение основного файла makefile, который компилирует все процессы, а не где находится makefile для этого процесса).
также нажмите "Подкаталоги также используются для компиляции" (мой подпроцесс makefile скомпилирован в подкаталоге основного местоположения)

Я не понял, как сделать это изменение для всех конфигураций отладки будущего и прошлого, так что мне не нужно добавлять этот каталог каждый раз, но я попытаюсь обновить его позже, если я это выясню.

Ответ 4

У меня была такая же проблема, но мое решение было другим. Откройте каталоги проекта "debug/src" + "release/src" и убедитесь, что нет файлов [filename].d, содержащих имя любых исходных файлов, которые могли бы изменить их имена или которые больше не существуют. У меня был один, удалил его и с тех пор не было больше ошибок.

Поэтому я предположил бы, по крайней мере, в моем случае, что ошибки создаются объектами, которые вышли из сферы действия.

Ответ 5

Это может произойти, если у вас есть как cygwin, так и mingw (или какой-то другой вариант). Если gcc из cygwin используется для компиляции источника, у вас будет путь cygwin в исполняемом файле. Затем, если отладчик находится из mingw, gdb не сможет интерпретировать путь cygwin. Самый простой способ решить это - перейти в Run → Debug Configurations → Debugger и установить полный путь к cygwin gdb (C:\cygwin64\bin\gdb.exe). Это решило проблему для меня.

Ответ 6

для существующего кода проекта Makefile. шаг 1 проверить компиляцию всех источников с -g -o0 шаг 2, используйте gdbserver и arm-yourversion-gdb, которые будут предоставлены в вашей программной цепочке sdk и gdb.