Команда symbol-file работает с более старым GDB, но не с более новым GDB - PullRequest
1 голос
/ 10 октября 2019

У меня проблема с тем, что в одной системе GDB я не могу заставить GDB использовать файл символов для показа мне исходных файлов и номеров строк в обратной трассировке, но в более старой системе с такими же командами это работаетхорошо. Более старая система, в которой это происходит, - это 32-разрядный Debian 6, а современная, где он не работает, - это 64-разрядный Debian 10.

В обоих случаях я собрал, запустил изапустил gdb в той же системе (поэтому не нужно пересекать двоичные файлы или ядра между системами)

Я могу воспроизвести это с помощью простой игрушечной программы (test.c), предназначенной только для немедленного сбоя:* Я компилирую его и делю на разделенный исполняемый файл и файл символов и запускаю исполняемый файл:

gcc -g test.c -o test
objcopy --only-keep-debug test test.dbg
objcopy --strip-debug test

ulimit -c unlimited
./test

Затем открываю дамп ядра в gdb. Когда я делаю это в более старой системе (32-битная, gdb 7.0.1-debian), я вижу обратную трассировку без каких-либо символов, но как только я запускаю symbol-file test.dbg, я вижу исходный файл и информацию о строке в обратной трассировке (test.c:4) (Я не включил некоторые ранние выходные данные GDB, которые загромождают экран, и я не думаю, что это уместно, я могу вставить его, если это необходимо)

gdb -c core test
Core was generated by `./test'.
Program terminated with signal 11, Segmentation fault.
#0  0x080483a4 in main ()
(gdb) symbol-file test.dbg
Reading symbols from /home/user/test.dbg...done.
(gdb) bt
#0  0x080483a4 in main () at test.c:4
(gdb) quit

Запуск точно такой же последовательности наболее новая машина (64-битная, gdb 8.2.1), я получаю следующее

Core was generated by `./test'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000055e5dda71135 in main ()
(gdb) symbol-file test.dbg
Load new symbol table from "test.dbg"? (y or n) y
Reading symbols from test.dbg...done.
(gdb) bt
#0  0x000055e5dda71135 in ?? ()
#1  0x000055e5dda71150 in ?? ()
#2  0x00007eff7035f09b in __libc_start_main (main=0x55e5dda71125, argc=1, argv=0x7fff46187ec8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff46187eb8)
    at ../csu/libc-start.c:308
#3  0x000055e5dda7106a in ?? ()
#4  0x00007fff46187eb8 in ?? ()
#5  0x000000000000001c in ?? ()
#6  0x0000000000000001 in ?? ()
#7  0x00007fff46188e8f in ?? ()
#8  0x0000000000000000 in ?? ()

Загрузка файла символов не только не добавляет источники и строки, но, похоже, теряет main ()в первом кадре. Я также попытался использовать add-symbol-file вместо symbol-file и включить файл символов в командной строке с параметром -s, но без каких-либо лучших результатов. Я также попытался поместить -s до -c, как я нашел рекомендуемый онлайн, но это тоже не помогло.

Редактировать : стенограмма, которая была запрошена ниже:

$ gcc -g test.c -o test
$ objcopy --only-keep-debug test test.dbg
$ ./test
Segmentation fault (core dumped)
$ gdb test.dbg core
GNU gdb (Debian 8.2.1-2+b1) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from test.dbg...done.

warning: core file may not match specified executable file.
[New LWP 26602]
Core was generated by `./test'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000056477c36d135 in ?? ()
(gdb) bt
#0  0x000056477c36d135 in ?? ()
#1  0x000056477c36d150 in ?? ()
#2  0x00007fa3a18a509b in __libc_start_main (main=0x56477c36d125, argc=1, argv=0x7ffd0b6aed38, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffd0b6aed28)
    at ../csu/libc-start.c:308
#3  0x000056477c36d06a in ?? ()
#4  0x00007ffd0b6aed28 in ?? ()
#5  0x000000000000001c in ?? ()
#6  0x0000000000000001 in ?? ()
#7  0x00007ffd0b6afe8d in ?? ()
#8  0x0000000000000000 in ?? ()
(gdb)

1 Ответ

1 голос
/ 11 октября 2019

Запустив точно такую ​​же последовательность на более новой машине (64-битная, GDB 8.2.1), я получаю следующее

Попробуйте построить ваш test двоичный файл с -fno-pie -no-pie.

Ваш рабочий пример имеет не-PIE-адрес (0x0804xxxx). Ваш нерабочий пример имеет адрес PIE (0x000055....). Debian решил сделать бинарные файлы PIE по умолчанию, что добавляет системе немного защиты.

Вероятно, случится так, что GDB выбрасывает информацию о перемещении при перезагрузке symbol-file.

* 1015. * PS Вы можете избежать всей этой проблемы, используя:
gdb test.dbg core

, который запускает GDB на правой ноге с самого начала.

PPS Обычно вообще плохая идея назвать любое имядвоичный файл test, потому что это может помешать оценке условий в оболочке (если оболочка находит ./test вместо /bin/test и не имеет test в качестве встроенного).

...