"Отсутствует источник для ошибки 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 → Разное → Другие параметры.