в моей отладочной сборке под linux gcc отсутствует информация о символах для некоторых из них

Я разветвил проект C на Github, который использует автоинструменты. После создания его с параметрами отладки, следуя сообщению Уильяма Перселла, я не могу войти в некоторые функции. Отладчик говорит: "нет отладочной информации".

Вот мой процесс сборки:

$ ./autogen.sh
$ mkdir Debug
$ cd Debug
$ ../configure --prefix=/Debug CPPFLAGS=-DDEBUG CFLAGS="-O0 -g3 -Wall"
$ make
$ make check

Для информации: дерево исходников имеет два уровня папок: perfo/, src/, src/core/, src/utils/,tests/ и т. д.

Когда я отлаживаю тесты/xxx, у меня есть символы для функций в тестах/xxx.c, но не в src/core/global.c, например.

Из информации здесь я пытались проверить объектные файлы, но похоже, что они имеют одинаковые свойства отладочной информации.

$ readelf -WS tests/reqrep.o | grep debug_info
  [ 6] .debug_info       PROGBITS        0000000000000000 00118a 000735 00      0   0  1
  [ 7] .rela.debug_info  RELA            0000000000000000 00d5d0 000d20 18     25   6  8
$ readelf -WS src/core/global.o | grep debug_info
  [ 6] .debug_info       PROGBITS        0000000000000000 002d87 002360 00      0   0  1
  [ 7] .rela.debug_info  RELA            0000000000000000 01ccb8 003180 18     25   6  8

Я отлаживаю с помощью Eclipse CDT. Профиль сборки отладки идентичен. Например, если я перестраиваю с нуля через консоль, Eclipse CDT не перестраивается при отладке, потому что он обновлен. Конечно, я пытался отлаживать как консольную сборку, так и сборку Eclipse. Конфигурация отладки выглядит нормально: приложение = Debug/tests/.libs/reqrep, использование GDB (DSF) с непрерывным режимом, конфигурация сборки — отладка, путь поиска исходного кода — по умолчанию.

Любая идея, пожалуйста?


gcc debugging eclipse-cdt debug-information
person lalebarde    schedule 14.01.2014    source источник
comment
Попробуйте посмотреть логи сборки. Есть ли вызовы gcc без -g3?   -  person n. 1.8e9-where's-my-share m.    schedule 14.01.2014
comment
В журнале сборки отображаются только CC и CCLD. Я предполагаю, что они определены Makefile с соответствующими параметрами. В противном случае я предполагаю, что не смог бы выполнить какую-либо функцию.   -  person lalebarde    schedule 14.01.2014
comment
Подробные журналы сборки: заголовок stackoverflow.com/questions/3793817/   -  person n. 1.8e9-where's-my-share m.    schedule 14.01.2014
comment
Каждая команда компиляции имеет набор -g3: $ grep "gcc -std=gnu99" xxx.build.log | wc -l 196 $ grep "gcc -std=gnu99" xxx.build.log | grep g3 | wc -l 195 $ grep "gcc -std=gnu99" xxx.build.log | grep -v g3 libtool: ссылка: gcc -std=gnu99 -shared -fPIC -DPIC ...etc...   -  person lalebarde    schedule 14.01.2014
comment
Все исходники скомпилированы? Существуют ли общие библиотеки?   -  person n. 1.8e9-where's-my-share m.    schedule 15.01.2014
comment
да на оба вопроса. Я обозначил проблему, но еще не решил ее. Проект представляет собой библиотеку с тестовыми программами. Помимо форка для работы над ним, я установил его через системный пакет. Когда я удалил его, исполняемый файл отладки (один из тестов) не смог загрузить библиотеку. Поэтому я должен где-то сообщить Eclipse, откуда он должен загрузить библиотеку. Это видно в интерфейсе, в отладочной конфигурации.   -  person lalebarde    schedule 15.01.2014
comment
Но все равно не работает /home/laurent/Documents/WorkSpace/xxx/Debug/tests/.libs/test1: error while loading shared libraries: libxxx.so.0: cannot open shared object file: No such file or directory   -  person lalebarde    schedule 15.01.2014
comment
Сообщение компоновщику, где найти библиотеку, не влияет на загрузку во время выполнения. Ваш исполняемый файл до сих пор не знает, где найти нужную общую библиотеку. Для этого существуют отдельные параметры компоновщика (-rpath и другие), но я не рекомендую использовать их для указания внутри вашего дерева проекта. Вместо этого используйте переменную среды LD_LIBRARY_PATH. Используйте -rpath, чтобы указать конечную папку установки, если она отличается от папки по умолчанию.   -  person n. 1.8e9-where's-my-share m.    schedule 15.01.2014
comment
Большое спасибо Вы спасли мой день. Я добавил LD_LIBRARY_PATH в переменные среды конфигурации отладки по пути, по которому он построен, и он работает.   -  person lalebarde    schedule 15.01.2014

Ответы (1)


arrow_upward
0
arrow_downward

Как пояснил Н.М. , решение состоит в том, чтобы добавить переменную среды LD_LIBRARY_PATH в конфигурацию отладки, указав путь, по которому создается библиотека.

введите здесь описание изображения

person lalebarde    schedule 15.01.2014