Как может dtrace помочь?

да у нас тут просто перечисление профайлеров, кто какие знает :)

Ему ж нужно чтоб вызов ушел в ядро, не? Если ты не обращаешься к ядру dtrace тебе наверняка ничего не покажет вообще

Ето про strace

Dtrace гораздо более широкий инструмерт

Корнями из Соляриса

То что он широкий инструмент это хорошо, но чтоб что-то мерять нужно сперва получить контроль над выполнением. Как он его получит?

Ну то есть, вот есть например sampling profiler, он периодически смотрит на текущую инструкцию и таким образом знает какая функция бинаря выполнена. Соответственно что если у тебя одноразовое событие то оно может вообще не попасть в профайл, т.е. для вышеобозначенной задачи не очень полезно. У тебя есть инструменты ядра типа strace и т.д. Когда отдается контроль ядру во время системного вызова, профилировщик встроенный в ядро может что-то сделать. Соответственно если ты не обращаешься к ядру, то этот механизм бесполезен. Есть еще дебаггер, который ставит hardware breakpoint и если процессор выполняет инструкцию по адресу breakpoint'a то контроль переходит профилировщику. Этот подход тоже мало полезен потому что емнип существуют аппаратные ограничения на количество breakpoint'ов и всюду ты их не расставишь. Да и муторно это в продакшне запускать бинарь под дебагерром.
Остается последний метод - code injection. Каждый раз выполняется функция, компилятор добавляет экстра код который записывает текущее состояние и его потом можно восстановить. Из минусов - просадка производительности (разна в зависимости от реализации) но бонусом идет 100% точность.

Code injection можно еще вручную делать :)

я как-то встречал в либах макросы а-ля BEGIN_FUNCTION() и END_FUNCTION()

вот прямо так и может. делаешь в нем пробу * и печатаешь

нет не нужно, он может и аппу так же обрабатывать

Хотелось бы иметь тулзу генератор таких макросов для проекта, чтобы получать все вызовы в виде дерева.
Очень странно, что до сих пор никто не заоупенсорсил такой генератор. Либо я плохо искал.
Да, просадка будет очень большая, но это не важно - важно, что мы точно узнаем где что пошло не так.
Не все проекты исторически писались аккуратно с обработкой кодов/исключений, про stacktrace вообще молчу.

https://myaut.github.io/dtrace-stap-book/app/proc.html вот здесь макросы DTRACE_PROBE1 вставляются для того чтоб dtrace что-то видел.

это для проб которые не вызовы функций.

о вызовах каких функций речь?

ну вот например из ядра экспортируется большая простыня, маленький кусочек:
56658        fbt            kernel               vm_phys_free_contig return
56659        fbt            kernel                      vm_phys_init entry
56660        fbt            kernel               vm_phys_scan_contig entry
56661        fbt            kernel               vm_phys_scan_contig return
56662        fbt            kernel               vm_phys_unfree_page entry
56663        fbt            kernel               vm_phys_unfree_page return
56664        fbt            kernel                   vm_radix_insert entry
56665        fbt            kernel                   vm_radix_insert return
56666        fbt            kernel                   vm_radix_lookup entry
56667        fbt            kernel                   vm_radix_lookup return
56668        fbt            kernel                vm_radix_lookup_ge entry
56669        fbt            kernel                vm_radix_lookup_ge return
56670        fbt            kernel                   vm_radix_remove entry

это не сисколы, это просто функции в коде, в макросы не обернуты

а указатели на них линкер дает?

ну как-то так наверное. я не разбирался как оно собирается для получениия такого эффекта. может объектник через утилиту какую прогоняется (но не сырцы)