Трассировка стека отладчика GCC отображает неверное имя файла и номер строки

Question

Я пытаюсь перенести довольно большой проект C ++ на использование g ++ 4.0 на Mac OS X. Мой проект компилируется без ошибок, но я не могу заставить GDB работать должным образом. Когда я смотрю на стек, набирая «bt» в командной строке GDB, все отображаемые имена файлов и номера строк неверны.

Например, согласно трассировке стека GDB, моя функция main() должна быть в stdexcept от Mac OS X SDK, что не имеет никакого смысла.

Что может привести к неправильной работе GDB? Я уже проверил в своем коде операторы #line и #file и убедился, что в коде есть только окончания строк Unix. Я также очистил и перестроил проект. Я также попытался отладить проект Hello World, и у него не было такой же проблемы.

Может ли проблема быть связана с одной из сторонних библиотек, на которые я ссылаюсь, и способом их компиляции? Или это что-то совершенно другое?

Вот два примерных вызова gcc и ld, выполненных Xcode . AFAIK все cpp-файлы в моем проекте скомпилированы и связаны с одинаковыми параметрами.

/ Разработчик / usr / bin / gcc-4.0 -x c ++ -arch i386 -fmessage-length = 0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -fpermissive -Wreturn-type -Wunused-variable -DNO_BASS_SOUND -D_DEBUG -DXCODE -D__WXMAC__ -isysroot / Developer / SDK MacOSX10.5.sdk -mfix-and-continue -fvisibility-inlines-hidden -mmacosx-version-min = 10.4 -gdwarf-2 -D_FILE_OFFSET_BITS = 64 -D_LARGE_FILES -D__WXDEBUG__ -D__WXMAC__ -c "/ Пользователи / adriangrigore / Documents / Gemswe Mac / TSDLGameBase.cpp "-o «/ Users / adriangrigore / Документы / Gemsweeper Mac / сборки / Gemsweeper Mac.build/Debug/Gemsweeper Mac.build/Objects-normal/i386/TSDLGameBase.o"

/ Разработчик / usr / bin / g ++ - 4.0 -arch i386 -isysroot /Developer/SDKs/MacOSX10.5.sdk «-L / Пользователи / adriangrigore / Документы / Gemsweeper Mac / сборки / отладки» -L / Разработчик / SDKs / MacOSX10.5.sdk / USR / местные / Библиотека -L / opt / local / lib "-F / Пользователи / adriangrigore / Документы / Gemsweeper Mac / сборки / отладки» -F / Пользователи / adriangrigore / Library / Frameworks -F / Разработчик / SDKs / MacOSX10.5.sdk / Library / Frameworks -файллист "/ Пользователи / adriangrigore / Документы / Gemsweeper Mac / сборки / Gemsweeper Mac.build/Debug/Gemsweeper Mac.build/Objects-normal/i386/Gemsweeper Mac.LinkFileList» -mmacosx-version-min = 10,4 /opt/local/lib/libboost_program_options-mt.a /opt/local/lib/libboost_filesystem-mt.a /opt/local/lib/libboost_serialization-mt.a /opt/local/lib/libboost_system-mt.a /opt/local/lib/libboost_thread-mt.a «/ Users / adriangrigore / Документы / Gemsweeper Mac / третий партия / FreeImage / Dist / libfreeimage.a» «/ Users / adriangrigore / Документы / Gemsweeper Mac / третий партия / CPUInfo-1,0 / libcpuinfo.a» -L / usr / local / lib -framework IOKit -framework Углерод -рамник Какао -рамка -рамка QuickTime -рамка OpenGL -фреймворк AGL -lwx_macd_richtext-2.8 -lwx_macd_aui-2.8 -lwx-2.x-x_x_x8 lwx_macd_adv-2.8 -lwx_macd_core-2.8 -lwx_base_carbond_xml-2.8 -lwx_base_carbond_net-2.8 -lwx_base_carbond-2.8 -framework SDL -рамка Cocoa -o "/ Пользователи / рекламные объявления Mac / сборки / Debug / Gemsweeper Mac.app/Contents/MacOS/Gemsweeper Mac "

Обратите внимание, что я уже задавал похожий вопрос относительно отладчика Xcode здесь , но я делаю репост, поскольку только что узнал, что это на самом деле не ошибка Xcode, а проблема с GCC / ld / GDB.

Редактировать: В моем проекте используются следующие сторонние библиотеки: SDL , Boost , wxWidgets . Я не уверен, имеет ли это значение для этой проблемы, но я просто хотел упомянуть об этом на всякий случай.

Я пытался скомпилировать шаблон проекта Xcode SDL и не столкнулся с той же проблемой, поэтому это должно быть связано с чем-то особенным в моем проекте.

Второе редактирование : Как я только что узнал, я сделал ошибку при поиске файлов со строкой «Это автоматически сгенерировано». Я только что нашел несколько десятков файлов с одинаковой строкой, все принадлежащие FreeImage , одной из сторонних библиотек, которые я использую. Итак, проблема, похоже, связана с FreeImage, но я до сих пор не уверен, что делать дальше.

Answer 1

У меня появились эти симптомы, когда моя версия GDB не соответствовала моей версии G ++.

Попробуйте получить новейший GDB.

Answer 2

Я пытался скомпилировать XCode SDL шаблон проекта и не сделал испытать ту же проблему, так что должно быть из-за чего-то особенного в моем проект.

Правильно. Настройки вашего проекта отличаются от других.

Вам нужно будет отключить оптимизацию отладки в настройках проекта XCode для сборки отладки. К сожалению, Xcode заставляет GDB переходить к странным строкам (не по порядку), когда вы ожидаете, что он будет двигаться последовательно.

Зайдите в настройки вашего проекта. Установите следующее

1) Instruction Scheduling   = None
2) Optimization Level       = None [-O0]
3) ZERO_LINK                = None

Ваши проблемы должны идти после этого. Вот экран настроек проекта, на котором вам нужно изменить настройки:

Answer 3

Может быть, вы используете SDL? SDL переопределяет main, так что ваш main будет называться SDL_main, и что части SDL могут быть сильно оптимизированы, поэтому у вас будут проблемы с получением хорошего вывода GDB.

... просто мысль

Читать это

Answer 4

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

Answer 5

Компилируете ли вы с оптимизацией? Я обнаружил, что O2 или выше довольно сильно портится с символами, делая файлы gdb и core практически бесполезными.

Также убедитесь, что вы компилируете с опцией -g.

Answer 6

В ваших файлах cpp есть символы отладки (опция -gdwarf-2).

Используете ли вы отдельный файл dSYM для символов отладки? Или они внутри объектных файлов. Сначала я попытался бы использовать DWARF в файлах dSYM и посмотреть, поможет ли это (или наоборот)

Сторонние библиотеки, похоже, являются сборками релизов (если, конечно, вы их не переименовали), например Я точно знаю, что boost использует моникер -d в именах библиотек для обозначения библиотек отладки (например, libboost_filesystem-mt-d.a).

Теперь это не должно создавать проблемы, это просто означает, что вы не можете вмешиваться в вызовы сторонних библиотек. (по крайней мере, не имеет никакого смысла, когда вы это делаете;) Но поскольку у вас есть проблемы, возможно, стоит попробовать связать с отладочными версиями этих библиотек ...

Answer 7

У меня есть новая вещь, которую вы можете попробовать.

Прямо перед вашим собственным main вы можете написать

#ifdef main
#  error main is defined
#endif

int main(int argc, char *argv[]) {

это должно выдать ошибку, если у вас есть заголовок, который переопределяет main.

Если вы определите свое собственное, вы можете получить предупреждение о том, что было сделано предыдущее определение

#define main foo

int main(int argc, char *argv[]) {

Вы также можете попробовать undef как раз перед вашим main

#undef main

int main(int argc, char *argv[]) {

Answer 8

Смотрите мой ответ здесь

Я сейчас скачал и скомпилировал исходники FreeImage, и да, файл b44ExpLogTable.cpp скомпилирован в libfreeimage.a. Проблема выглядит так: сценарий gensrclist.sh просто собирает все файлы .cpp, не пропуская файл с основным входом. Этот сценарий создает файл с именем Makefile.srcs, но один уже поставляется. (запуск его на моем Leopard не удался, некоторые проблемы с sh - это работало, если я изменил sh на bash)

Прежде чем вы что-либо изменили, это дает a.out

c++ libfreeimage.a

Файл Makefile.srcs уже создан, поэтому вы сможете удалить из него файл b44ExpLogTable.cpp. Тогда сделай

make -f Makefile.osx clean
make -f Makefile.osx

Когда это будет сделано, вышеприведенное c++ libfreeimage.a должно выдать следующую ошибку

Undefined symbols:
  "_main", referenced from:
      start in crt1.10.5.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

Answer 9

WxWidgets также определяют свои собственные main, если вы используете их IMPLEMENT_APP() макрос

С здесь

Как и во всех программах, должна быть «основная» функция. Под wxWidgets main реализован с помощью этого макроса, который создает экземпляр приложения и запускает программу.

IMPLEMENT_APP(MyApp)

Answer 10

Я столкнулся с этим несколько лет назад при переходе от компиляторов Codewarrior к Xcode. Я считаю, что способ обойти это - поставить флаг "-fno-inline-functions" в другие флаги Си (только для разработчиков).

Эта проблема была более заметна для нас в архитектуре PowerPC.

Как быть, если вы удалите флаги "-fvisibility-inlines-hidden" и "-mfix-and-continue"?

У меня никогда не было возможности исправления и продолжения для меня.