Осилил DTrace SDT и язык D

D оказался не таким уж и богатым по возможностям. Для своей рабочей
библиотеки заюзал почти все функции и стал понимать кучу других
скриптов. Сила DTrace то конечно в самих имеющихся probe-ах, но я пока
только со своими собственными userspace SDT имел дело в основном. Чуть
чуть обмазав код probe-ами уже полезные результаты получаю прогоняя весь
цикл программы.

Не обошлось без хаков. Насколько понял, Solaris (SunOS), будучи типа
первопроходцем динамической линковки, очень её любит и поэтому DTrace из
коробки не особо то дружит с статическими библиотеками. А объектные
файлы программы надо пропускать через dtrace -G чтобы он их "подправил"
вкупе со всеми остальными зависимостями и добавил DTrace вызовы вместо
пустышек. В итоге ничего лучше не придумал чем... во временной
директории распаковывать объектные файлы из .a библиотеки и их вместе с
.o самой программы обрабатывать dtrace -G и уже это всё вместе собирать.

dtrace -h и -G отрабатывают и под GNU/Linux в составе systemtap-sdt-dev
и успешно собирает целевые программы, внутри которых честные STAP пробы.
Везде читал, ещё давно, что SystemTap та ещё редиска. Не помню причин
точных, но вроде как DTrace это штука которая с минимальнейшим
overhead-ом может миллионы событий отслеживать/обрабатывать и с
гарантией что это никак не может повлиять на работу системы, тогда как
SystemTap может вообще всё обрушить. Ну как всегда в GNU/Linux
экосистеме: всё всегда меняется, делается обратно-несовместимым и
поэтому нафиг никому не нужным. А ещё для SystemTap нужно каждый раз
компилировать модуль для ядра для его загрузки, тогда как DTrace
моментально in-place запускается и я за минуту по несколько раз скрипт
успеваю переписать чтобы посмотреть что из этого выйдет.

Но SystemTap инструментарий я в итоге не заюзал, а потрогал bpftrace и
bcc. В общем то, что относится к модному eBPF. Статей много на тему eBPF
и USDT под GNU/Linux... но буквально *ни одна* не отрабатывает на
какой-то относительно свежей Ubuntu в виртуалке. Команды, присутствующие
в статьях, отсутствуют местами. Как установить bcc пакет (или что-то
такое) я не нашёл, но каким-то образом поставил snap-нечто. Какие-то в
статьях сплошные скрипты на Python... понятия не имею откуда взявшиеся
(точнее они когда-то в каких-то версиях пакетов присутствовали). В
общем, беря по абзацу из самых разнообразных статей, даже из
русскоязычных, я смог получить список проб и одну какую-то после запуска
программы я даже смог увидеть. В FreeBSD/Solaris всё это вопрос пары
минут, а в популярнейшем дистрибутиве GNU/Linux популярнейшая модная и в
тренде eBPF тема заняла у меня наверное полдня чтобы просто получить
хоть одну пробу. Даже забавно: название некоторых вещей должно совпадать
с названием исполняемого файла. В Github проектах это всё фиксят, но...
блин, дистрибутив свежайщий, но в нём придётся делать переименование
исполняемого файла чтобы получить работоспособные пробы!? Как же я
ненавижу всю эту экосистему! Это чистейшая Windows/macOS по своему
качеству и дружелюбности к разработчику. Всё через задницу, всё сделано
на коленке, ничего нет отточенного, просто работающего, просто достойно
сделанного. В общем, убедившись что пробу как-то да можно получить --
выключил виртуалку и считаю что если кому надо, то в моей Си библиотеке
он сможет это получить. USDT код будет работать везде.

Зато продолжает без устали и останова радовать redo. Как с ним легко всё
это встраивать, переключать "хочу DTrace-able библиотеку или нет",
каждый .o файл post-processing-овать dtrace-ом (оказалось не нужно,
бесполезно, но проще было сделать и проверить) через default цели и всё
подобное. dtrace -G делает вообще не очень приятную штуку: он буквально
in-place редактирует объектные файлы, что, с точки зрения redo, выглядит
как изменение уже выполненных целей без участия/учёта самой redo системы.
Кажется что добавляется геморрой. Но нет -- оно просто вынуждает
написать сборку так, чтобы всё было атомарно, пускай и через копирование
файлов во всякие временные директории. redo хорошо дисциплинирует и
показывает огрехи подходов!