Отсутствие номеров строк в отладочных символах для библиотеки во всей программе, но не само по себе - PullRequest
4 голосов
/ 21 июля 2011

Я вижу странную проблему при попытке использовать gdb для отладки тестовой программы для пакета, созданного с помощью libtool. Если я запускаю libtool --mode=execute gdb .libs/libfoo.so и прошу указать источник какой-либо функции list Bar::Baz, я получаю исходный код, как и ожидалось. Если я запускаю libtool --mode=execute gdb binary, я могу взломать Bar::Baz() и увидеть его аргументы в трассировке стека, но я не получаю исходный файл или номера строк, например:

#7  0x018348e5 in Bar::Baz(Qux*, Quux*) () from /path/to/libfoo.so
                           ^^^^^^^^^^^ <--- debug symbols are present!

Аналогичным образом, если я пытаюсь list Bar::Baz при отладке исполняемого файла, я получаю

No line number known for 'Bar::Baz'.

Я подтвердил, что двоичный файл связан с -g, и я могу перечислить его функцию main, поэтому я знаю, что присутствует некоторая отладочная информация.

Когда я говорю info sources, я получаю полный список файлов, из которых построена библиотека, с правильными абсолютными путями. Когда я говорю info shared, я получаю правильный путь в списке к объектному файлу с Yes в столбце Syms.

Есть еще идеи, что может пойти не так и как это исправить?


Редактировать 1: Я случайно запустил objdump -g в библиотеке, которая нарушает работу, и получил следующий вывод:

/path/to/foo.so.0.0.0: file format elf32-i386
objdump: /path/to/foo.so.0.0.0: no recognized debugging information

Это удивительно, поскольку objdump -h (что я пытался запустить) перечисляет кучу .debug_* разделов. Руководство objdump также предлагает readelf -w, и это, кажется, печатает огромную кучу информации. Мне нужно посмотреть, что он на самом деле дает.


Редактировать 2: Итак, readelf -w дал некоторое просветление. По какой-то причине файл общего объекта не содержит отладочной информации из подавляющего большинства любых объектов, связанных с ним. Основываясь на файлах Makefile, возможно, что команда, которая фактически собирает объекты в разделяемую библиотеку, не передается -g, и поэтому информация не распространяется должным образом. Самое смешное, что это работает (имеет полную отладочную информацию) на всех других наших конфигурациях, включая ту же версию компилятора на x86_64 (по сравнению с нынешним x86).


Редактировать 3: На самом деле прошла полная перестройка с измененным Makefile с добавлением -g в LDFLAGS, и это не имело никакого значения. Теперь я хорошо и по-настоящему сбит с толку.

Ответы [ 3 ]

5 голосов
/ 04 ноября 2011

Это ответ на старый вопрос, но ваша проблема совпала с моей, но ни одно из решений не сработало.Вот что сработало для меня.

Измените CFLAGS -g на "-g -gstabs".

objdump не распознал отладочную информацию стиля дварфа.-gstabs меняет этот формат на тот, который работает с objdump -g и objdump -S и моим отладчиком.

Надеюсь, это поможет.

ПРИМЕЧАНИЕ: Для меня я собирал ядро ​​Linux.Это изменение было сделано в Makefile ядра Linux.

2 голосов
/ 21 июля 2011

Ваша первая путаница: Bar::Baz(Qux*, Quux*) означает , что не означает, что присутствуют символы отладки (и фактически подразумевает, что они не присутствуют).

Отладчик просто разбирает имя функции.Если бы на самом деле присутствовали символы отладки, вы бы увидели Bar::Baz(Qux* qux = 0x12..., Quux* quux = 0x234...)

Что касается реальной проблемы, я подозреваю, что символ определен в некоторой другой библиотеке, которая

  • появляется в строке ссылки для двоичного файла раньше, чем libfoo.so, а
  • был построен без символов отладки

(Загрузчик времени выполнения свяжет ссылку сBar::Baz() к первому определению, которое он видит.)

Если вы напечатаете ip в кадре # 7, а затем выполните info symbol <value-just-printed>, я подозреваю, у вас будет "Ага!"момент.

РЕДАКТИРОВАТЬ: Ваше обновление сделало ваш вопрос противоречивым.AFAICT,

  1. gdb может видеть символы отладки при выполнении
    libtool --mode=execute gdb .libs/libfoo.so
  2. , но не при выполнении libtool --mode=execute gdb binary
  3. выпроверил, что определение символа происходит от точных тех же .libs/libfoo.o
  4. и readelf -w не видит отладочные символы в .libs/libfoo.o

Atпо крайней мере одно из приведенных выше утверждений скорее всего ложно.

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

Также обратите внимание, что добавление -g к LDFLAGS, как правило, неправильно .Вы хотели добавить его к CXXFLAGS вместо этого?

0 голосов
/ 31 июля 2011

Что-то заставило меня задуматься, что выводит show language, когда у вас возникают проблемы.Если это не c++, может быть, set language c++ необходимо?

...