g ++ и gdb проблема: отладочные символы для общих библиотек, не найденных

Я портирую большой набор приложений и библиотек от 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 не имеют символов также?

Любые идеи очень ценились бы.

1
задан 4 December 2018 в 02:37

2 ответа

Проблема была в конечном счете разыскана к пользовательскому m4 макросу прежней версии. Это не удалось обнаружить пакет библиотеки и ударило свой вклад в переменные, которые были записаны в Makefile.in для, включают пути. Результатом был-I без пути в последовательности многих-I директив. Странно это не произвело ошибки..., но это, действительно казалось, вызвало-g опцию, которая сразу следовала за ним, чтобы "глотаться". (Результатом был длинный список путей-I, которые закончились "-I-g". Похоже, что это предотвратило g ++ от обработки-g опции.).

Исправление ошибочного m4 макроса для создания непустого и допустимого включает путь к файлу, решил проблему.

1
ответ дан 7 December 2019 в 15:10

Необходимо использовать-g в команде компиляции. См. страницу справочника для gcc в названном разделе: Опции для Отладки Вашей Программы, у Них есть некоторые предостережения при использовании с-O опцией.

0
ответ дан 7 December 2019 в 15:10

Другие вопросы по тегам:

Похожие вопросы: