Как отлаживать программы на C ++ 0x в MacPorts gcc 4.5? - PullRequest
8 голосов
/ 28 июля 2010

У меня есть простая программа на С ++, которую я пытаюсь отладить, но GDB не может найти объектный файл для библиотек (или нет доступной информации об отладке), и он также не может найти символы отладки для моего исполняемого файла.

Я нахожусь на OSX 10.5.8 с macports, и я компилирую свой код с помощью

g ++ - mp-4.5 -Wall -pedantic -std = c ++ 0x -g-ggdb -I / opt / local / include -L / opt / local / lib -lgsl -static-libstdc ++ MCMC-simplex.cpp -o mcmc

(есть только один файл и g ++-mp-4.5 - исполняемый файл macports для gcc / g ++ 4.5)

Когда я пытаюсь запустить gdb для получающегося исполняемого файла, я получаю много сообщений об ошибках (при запуске) в форме

предупреждение: не удалось найти объектный файл "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc45/work/build/i386-apple-darwin9/libgcc/trunctfdf2_ug доступ к информации - deb для информации - deb../../../gcc-4.5.0/libgcc/../gcc/config/soft-fp/trunctfdf2.c".

, что для меня означает, что у macports есть ошибка во время его сборки (кажется, что GDB ищет объектные файлы во временном каталоге сборки).

Я должен добавить это, когда я пытаюсь увидеть список своих программв gdb (предоставленном Apple) он пытается найти случайный файл .s в /var/tmp, который для меня звучит как файл ассемблера.Вот почему я говорю, что он также не может найти символы отладки для моей программы.

Когда я пробую MacPorts gdb 7.1, я получаю предупреждение

: `/ var /Папки / Xa / XaqHO9PeEC8K-Nrd0L9xWk +++ TM / -Tmp - // cc2IvFto.o ': невозможно открыть для чтения символов: такого файла или каталога нет.(символы отладки не найдены) ... готово.

и ни одно из множества сообщений об ошибках, которые выдает GDB от Apple (хотя конечный результат тот же).

Есть кто-нибудьсталкивался с этой проблемой и придумал решение?

Ответы [ 3 ]

11 голосов
/ 31 июля 2010

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

Если вы удалите объектные файлы, вы не сможете отлаживать.

Когда вы компилируете и связываете исполняемый файл в «один шаг», GCC делает это:

  1. Создать файл сборки /tmp/[random-string].s
  2. Соберите его в /tmp/[random-string].o
  3. Связь /tmp/[random-string].o с crt0.o, libc и т. Д. В mcmc исполняемом файле.
  4. Удалить /tmp/[random-string].o и .s

Это последний шаг, который мешает вам отладки.

Решение:

g++-mp-4.5 -Wall -pedantic -std=c++0x -g -ggdb -c MCMC-simplex.cpp
g++-mp-4.5 MCMC-simplex.o -lgsl -static-libstdc++ -o mcmc

Это оставит MCMC-simplex.o в текущем каталоге и позволит GDB найти в нем отладочную информацию.

5 голосов
/ 12 ноября 2010

Что ж, еще один «трюк», который нужно выполнить с одним шагом компиляции и компоновки, заключается в добавлении
-save-temps=obj
в вашу командную строку g ++, чтобы

4 Удалите /tmp/[random-string].o и .s

на самом деле не выполняется (на самом деле канонические файлы SOURCE.o и SOURCE.s оказываются в каталоге, гдевы строите вместо RANDOM-STRING. [os] в некоторых временных папках, но с точки зрения поиска символов отладки это нормально

2 голосов
/ 08 апреля 2011

Мне кажется, у вас было две проблемы: 1) нет символов отладки для исполняемого файла и 2) нет символов отладки для некоторых общих библиотек, которые генерировали предупреждения.У меня также была проблема 2).Работающий русский ответил 1) и указал мне правильное направление для 2).

Во-первых, если вам не нужно отлаживать библиотеки, упомянутые в предупреждениях, то их можно безопасно игнорировать.Но, конечно, предупреждения раздражают и могут скрывать другие проблемы.В вашем и моем случае библиотеки, установленные MacPorts, должны были удалить символы отладки, но не сделали этого.Причина, по которой возникает предупреждение, заключается в том, как говорит Employed Russian, потому что сами символы хранятся в объектных файлах, созданных в процессе сборки, а не в установленных библиотеках.Библиотеки хранят указатели на объектные файлы как часть их (минимальной) отладочной информации.

Это можно проверить с помощью команды strings.Если вы получаете предупреждение о том, что /crazy/path/to/something.o не может быть найдено при загрузке libsomething.dylib:

strings - libsomething.dylib | grep something.o

Обратите внимание, что вам нужен '-' (это дало мнев первый раз).

Чтобы исправить это, удалите отладочную информацию примерно так:

strip -S libsomething.dylib

После этого 'dwarfdump --file-stats libsomething.dylib' должно показать, что «STABS debug»раздел пуст(Ссылки на объектные файлы хранятся в формате отладки STABS.)

Больше никаких уродливых предупреждений .. ууу!

Это было способом слишком сложно.

...