7.8. Компиляторы и инструменты разработки (машинный перевод)

Синтетические функции, генерируемые GCC, путают SystemTap

Оптимизация GCC может генерировать синтетические функции для частично встроенных копий других функций. Такие инструменты, как SystemTap и GDB, не могут отличить эти синтетические функции от реальных функций. Как следствие, SystemTap может размещать зонды как в точках входа в синтетическую, так и в реальную функцию, и, таким образом, регистрировать несколько попаданий зондов для одного вызова реальной функции.

Чтобы обойти эту проблему, сценарии SystemTap должны быть адаптированы к таким мерам, как обнаружение рекурсии и подавление проб, связанных с встроенными частичными функциями. Например, скрипт

probe kernel.function("can_nice").call { }

Можно попытаться избежать описанной проблемы следующим образом:

global in_can_nice%

probe kernel.function("can_nice").call {
  in_can_nice[tid()] ++;
  if (in_can_nice[tid()] > 1) { next }
  /* code for real probe handler */
}

probe kernel.function("can_nice").return {
  in_can_nice[tid()] --;
}

Обратите внимание, что в этом примере сценария не учитываются все возможные сценарии, такие как пропущенные kprobes или kretprobes или подлинная предполагаемая рекурсия.

(BZ#1169184)

ltrace инструмент не сообщает о вызовах функций

Из-за улучшений бинарного упрочнения, применяемых ко всем компонентам RHEL, ltrace Инструмент больше не может обнаруживать вызовы функций в двоичных файлах, поступающих из компонентов RHEL. Как следствие, ltrace вывод пуст, потому что он не сообщает о каких-либо обнаруженных вызовах при использовании таких двоичных файлов. В настоящее время нет обходного пути.

Как примечание, ltrace может правильно сообщать о вызовах в пользовательских двоичных файлах, созданных без соответствующих флагов защиты.

(BZ#1618748, BZ#1655368)