Как влияет читаемость трассировки стека GDB кода выпуска на x64?

Question

Я работаю над проектом, в котором поступил запрос "мы хотим получить больше информации о трассировках стека сборки сборки".

Под "трассировкой стека" я имею в виду вывод of t a a bt in gdb, который я предполагаю эквивалентным выводу gstack для запущенного процесса.Если это правда, то это был бы один из моих вопросов.

Моя главная проблема в том, что наличие трассировок стека довольно нестабильно (иногда они есть, иногда нет), а документация может быть более подробной (например, *Документация 1007 * гласит, что «-fomit-frame-pointer делает невозможной отладку на некоторых машинах», без какой-либо четкой информации о x86_64)

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

В настоящее времякод скомпилирован с -O2.В последнее время я видел одну трассировку стека, где кадры стека нашего собственного программного кода не имели каких-либо значений параметров функции, но первые (внутренние) кадры, где наш код уже назывался сторонней библиотекой, предоставляли эти значения.Здесь я не уверен, является ли это признаком того, что в сторонней библиотеке установлены лучшие параметры отладки gcc, или эта информация просто теряется в какой-то момент итерирования по трассе стека.

Я полагаю, мои вопросы:

• Какие параметры компилятора влияют на качество трассировки стека на x86_64
• , идентичны ли трассировки стека из этих источников:
  • вывод gstack работающей программы
  • подключил gdb к работающей программе, исполняется t a a bt
  • , вызывается gcore на работающей программе, открывается ядро ​​с помощью gdb, затем t a a bt
  • программа прерванаи файл ядра, записанный системой, открываемый с помощью gdb
• Существует ли какая-либо подробная документация, параметры которой влияют на качество трассировки стека на x86_64?

Всесоображения, сделанные в предположении, что двоичный файл программы существует для дампа ядра, а исходный код недоступен.

Под «качеством трассировки стека» я подразумеваю 3 критерия:

• КалифорнияДоступны именованные функции, а не только «??»
• Доступно имя файла с исходными кодами и номер строки
• Доступны параметры вызова функции.

Answer 1

Какие параметры компилятора влияют на качество трассировки стека в x86_64

-fomit-frame-pointer является значением по умолчанию для x86_64, а не вызывает трассировку стека вбыть непригодным для использования.

GDB полагается на дескрипторы раскрутки, и вы могли бы удалить их с помощью strip или -fno-unwind-tables (это ill -Advised).

- трассировки стека из этих источников идентичны:
- вывод gstack работающей программы

В последний раз, когда я посмотрел, gstack был тривиальным сценарием оболочки, который вызывалсяgdb, да так.

• подключил gdb к запущенной программе, выполнил "taa bt"

Да.

• вызывается gcore в запущенной программе, открывая ядро ​​с помощью gdb, затем "taa bt"

Да, при условии coreоткрывается с помощью GDB в той же системе , где запускается gcore.

• программа прервана и файл ядра записан системой, открыт с помощью gdb

То же, что и выше.

Если вы пытаетесь открыть core в другой системе, отличной от той, в которой он был создан, и двоичный файл использует динамические библиотеки, вам необходимо set sysrootсоответственно.См. этот вопрос и ответ.

Обратите внимание, что существует несколько причин, по которым стек может выглядеть поврежденным или недоступным в GDB:

• -fno-unwind-tables или stripупомянутый выше
• код, скомпилированный из сборки, и без надлежащих директив .cfi
• сторонних библиотек, которые были собраны с очень старым компилятором и имеют некорректные дескрипторы размотки (что-либо до gcc-4.4 былоочень плохо).
• и, наконец, повреждение стека.