Я портирую большой набор приложений и библиотек от Debian 7 до Ubuntu 16.04. Это - проект автоинструментов GNU, таким образом, libtool включен. gdb не может найти символы для большинства общих библиотек, даже при том, что я создаю с опциями, которые всегда работали на меня прежде. Я задаюсь вопросом, встретился ли кто-либо еще с этой проблемой, и раз так какие рекомендации они могли бы иметь.
Я использую gdb версию 7.11.1-0ubuntu1~16.5 Ubuntu), 7.11.1.
Я компилирую с-g O0 и другими параметрами компилятора. Эти опции последовательно используются при создании 12 библиотек. Точно один из них появляется из процесса сборки с отладочной информацией. Мы будем определять тот один libA. (В обсуждении ниже, просто замена на путь проекта.)
Не учитывая много-I директив, используемые опции:
-g -O0 -Wconversion -Woverloaded-virtual -Wall -Werror -Wreturn-type -
Wformat -Wparentheses -Wswitch -Wno-deprecated -Wsign-compare -fno-
strict-aliasing -Wunused -D__STDC_LIMIT_MACROS -MT MyModule.lo -MD -MP
-MF .deps/MyModule.Tpo -fPIC -DPIC -o .libs/MyModule.o
Когда я смотрю на libA, использующий gdb, файл и другие утилиты, он выглядит хорошо.
u16dev01:(18:01:32):file libA.so.0.0.0 ~/dev/product-
<path>lib/liba/.libs
libA.so.0.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
dynamically linked,
BuildID[sha1]=14dc765142914be4c32a07eaa1683b5b2a2f6dae, not stripped
Объектные файлы похожи на это:
u16dev01:(18:01:43):file AModule1.o
<path>/lib/liba/.libs
AModule1.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not
stripped
Если я открываю общую библиотеку с gdb, у меня есть символы, и я могу перечислить код. Если я открываю какой-либо из его.o файлов с gdb, я получаю символы и могу перечислить код.
Из оставления 11, команда файла сообщает два как являющийся SYSV и другими 9, как являющимися GNU/Linux, например:
u16dev01:(18:08:34):file libD.so.0.0.0
~/<path>/lib/.libs
libD.so.0.0.0: ELF 64-bit LSB shared object, x86-64,
version 1 (GNU/Linux), dynamically linked,
BuildID[sha1]=059733fbc888c3dce86eae21984ea82cddc5b0e9, not stripped
gdb не видит символов, когда я открываю эту библиотеку или любой из ее.o файлов. Команда файла также сообщает о GNU/Linux для.o файлов. Нет никаких символов.
Существует две библиотеки, о которых файл сообщает как SYSV. Их.o файлы также лишены отладочной информации и библиотеки - также.
Я переименовал программу полосы для устранения возможности Make-файлов от рабочей полосы, даже при том, что тщательный поиск выхода компилятора сказал мне, что это не было. Таким образом, это не случай символов, разделяемых после сборки библиотеки.
Я пытался создать немного тестовой библиотеки, с помощью параметров компилятора моего проекта. Это создает библиотеку SYSV, и gdb загружает отладочные символы очень хорошо.
objdump-g вывод редок в случаях, когда gdb не может загрузить символы.
Я и несколько моих коллег царапали наши головы по этому в течение нескольких дней теперь. Почему процедура сборки производит жизнеспособные символы для только одной из библиотек? Нет ничего специального о той библиотеке. То, почему 9 из оставления 11, сообщило, что GNU/Linux и 2 сообщил как SYSV? Почему те 2 не имеют символов также?
Любые идеи очень ценились бы.
Проблема была в конечном счете разыскана к пользовательскому m4 макросу прежней версии. Это не удалось обнаружить пакет библиотеки и ударило свой вклад в переменные, которые были записаны в Makefile.in для, включают пути. Результатом был-I без пути в последовательности многих-I директив. Странно это не произвело ошибки..., но это, действительно казалось, вызвало-g опцию, которая сразу следовала за ним, чтобы "глотаться". (Результатом был длинный список путей-I, которые закончились "-I-g". Похоже, что это предотвратило g ++ от обработки-g опции.).
Исправление ошибочного m4 макроса для создания непустого и допустимого включает путь к файлу, решил проблему.
Необходимо использовать-g в команде компиляции. См. страницу справочника для gcc в названном разделе: Опции для Отладки Вашей Программы, у Них есть некоторые предостережения при использовании с-O опцией.