"Отсутствует источник для ошибки main()" при отладке простого С++ в Eclipse с помощью gdb

У меня возникла проблема с отладкой С++-программы в Eclipse (последний RC Helios, обновленный с помощью самого последнего CDT изнутри) на OSX.

Программа очень проста (в настоящем уроке 2 из уроков NeHe OpenGL), состоящая из одного файла cpp и с использованием OpenGL и Cocoa фреймворков и связывания с libSDL.a и libSDLmain.a.

Структура проекта очень проста: исходный файл находится в подкаталоге проекта src/, а исполняемый файл создается в корневом каталоге проекта.

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

Флаги компилятора имеют оптимизацию, равную none, и оба компилятора и компоновщика имеют флаг флагов отладки (-g).

В настройке отладки в Eclipse установлено значение "Standard spwn progess", а для отладчика установлено значение "gdb".

Теперь самое странное, что если я попытаюсь отлаживать тот же самый исполняемый файл - то есть. то же самое, что было построено Eclipse - используя gdb из Terminal (shell), тогда все работает нормально. Точки останова попадают, отображается исходный код, никаких проблем вообще.

Я убедился, что оба Eclipse и оболочка используют один и тот же исполняемый файл gdb, и они (it/usr/bin/gdb).

Теперь я могу ошибаться, но это все говорит мне, что не может быть проблемы с флагами компилятора и компоновщика (поскольку тот же исполняемый файл отлаживается из оболочки), поэтому, вероятно, проблема должна быть связана с тем, как gdb вызывается из Eclipse? Возможно, при запуске из Eclipse gdb собирает различные файлы конфигурации или что-то, чем когда он запускается из оболочки? (Кто-нибудь знает?)

Я бы очень признателен за любую помощь в этом, потому что он медленно меня зацикливал!

Пожалуйста, дайте мне знать, если будут какие-либо другие детали, которые были бы полезны - точные номера версий Eclipse/cdt/gdb, точные строки компоновщика/компилятора и т.д. - и я очень с удовольствием обновлю эту запись с ними.

Большое спасибо заранее,

thoughton.

--- отредактировано @ "14 часов назад" ---

Я попробовал "добавить путь к файловой системе" (с опцией "поиск подпапок" ), но это не сработало. Я также попытался создать новый полностью плоский проект, но это тоже не сработало. Я даже попытался получить выпуск Galileo (eclipse-SDK-3.5.2RC4 с обновлением CDT), но это не имело никакого значения (кроме того, что gdb медленнее запускать).

И вот что-то еще странное, что я заметил: как только я получаю сообщение "Нет источника", если я затем переключу консоль Eclipse, чтобы отобразить консоль "gdb", а также включите "Verbose console mode", чтобы я мог сообщить об этом, Я могу затем выполнить команды "l" и "bt" и заставить их работать успешно, показывая правильный источник и стек, где была удалена точка останова. Который, исправьте меня, если я ошибаюсь, должен означать, что информация есть, и gdb вызывается правильно - так почему Eclipse не увидит эту информацию?

Я сближаюсь с тем, чтобы отказаться от Eclipse, чтобы быть честным... Я тоже пришел к этому с такими большими надеждами.

Любая дополнительная помощь или мысли были бы чрезвычайно оценены.

т.

Ответ 1

Я нашел ответ! И это смущающе просто.

Проблема заключалась в том, что я использовал версию Release SDL вместо версии Debug! (У меня был "libsdl" из MacPorts, тогда как у меня должен был быть "libsdl-devel".)

Итак, мой общий ответ: убедитесь, что libs, с которым вы связываетесь, были скомпилированы с установленными слишком флаговыми флагами, это не всегда достаточно, чтобы убедиться, что ваш собственный код установлен.

Ответ 2

Этот поток предлагает:

-g -O0

для флагов отладки, которые будут установлены для компиляции CDT Eclipse.
Когда-то это просто проблема полного восстановления приложения (как здесь)

См. также этот поток, описывающий аналогичную ситуацию:

Я заметил, что иногда в Eclipse мне нужно пойти и конкретно добавить путь к моим исходным файлам, используя "add filesystem path" (с "search sub-folders" ) в диалоговом окне "Отладка" (даже если они находятся в одном и том же проект, который я отлаживаю), но я не заметил шаблона, когда мне нужно это сделать. Но, возможно, стоит попробовать.

Ответ 3

Вот еще одна причина для этой проблемы. Моя конфигурация использовала -g3 как вариант для gcc. Изменение его на -g решило проблему. Кажется, существует некоторая несовместимость между gcc и gdb. Я проверил, что gdb является последней версией (с помощью apt-get).

Ответ 4

Я хотел бы добавить немного новой крови к этой старой теме.

Я столкнулся с этой проблемой, когда попытался скомпилировать и отладить проект gnu arm.

Я решил проблему, изменив Makefile: добавив "-g -O0" в конце этой строки "CFLAGS + = -Wall -Werror -O3"

Ответ 5

Перейдите в Project Properties, C/С++ Build → Settings. На первой вкладке ( "Параметры инструмента" ) в разделе "Компонент Cross GCC" нажмите "Отладка" и установите "Уровень отладки до максимума (-g3)

Ответ 6

У меня была эта проблема, когда я скомпилировал последнюю версию gcc, но не обновлялся до последнего gdb. После обновления он работал правильно.

Ответ 7

Для всех, кто может столкнуться с этой проблемой,

Я установил плагин linuxtools/valgrind вчера вечером, чтобы сделать некоторое профилирование памяти, и кажется, что это нарушило нормальный gdb. когда я удалял плагины linuxtools, все снова начинало работать как обычно.

Итак, вы можете попробовать это.

Ответ 8

У меня была аналогичная проблема. Я использовал CFLAGS=-Wall -O2 -fPIC -DPIC -lm -lasound и никогда не имел проблемы с его компиляцией, но когда я попытался дебютировать на Eclipse IDE, я получил эту ошибку: No source available for "main() at 0x401080", затем я добавил -g в эту строку, и она хорошо работала:

CFLAGS = -g -Wall -O2 -fPIC -DPIC -lm -lasound

Ответ 9

Предположим, что если вы используете cmake для создания проекта, одним из подходов к решению будет добавление "флага отладки" в команду cmake, то есть -

$cmake/path/to/main/cmake_file - DCMAKE_BUILD_TYPE=Debug

Ответ 10

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

Использование версии для версии отладки или отладки библиотеки может быть вашей конкретной проблемой (если вы строили библиотеку из источника, а затем отлаживали ее). Если кто-то использует предварительно скомпилированную библиотеку, они никогда не смогут установить точки останова в нем, и поэтому исправление не будет применяться к ним.

Ответ 11

Однажды столкнулся с той же проблемой. Вам просто нужно перейти к свойствам вашего проекта, нажав ALT + ENTR или щелкнув правой кнопкой мыши по проекту и прокрутив вниз, и вы найдете свойства. Разверните C/C++ сборку слева. Затем нажмите на настройки. После того, как вы откроете настройки, затем нажмите на настройки инструмента. В компиляторе MCU GCC есть опция отладки. Нажмите на отладку и добавьте

-g -O0

в Другие флаги отладки. Попытка отладки проекта сейчас.

Ответ 12

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

Убедитесь, что аргументы приложений и программ C/C++ указывают на один и тот же двоичный файл.

Ответ 13

Похоже, это сообщение может иметь много причин для показа.

Для меня (в контексте отладки микроконтроллера) это была оптимизация времени соединения. С -flto он сломался; удаление -flto из поля "Другие параметры" исправило это для меня.

В Eclipse Neon (4.6) см. проект → Свойства → C/C++ Сборка → Настройки → Настройки инструмента → Компилятор C → Разное → Другие параметры.