Что: 060b63251ef2c81ad42baca7dba8caa79c573211
Когда: 2021-04-06 21:30:20+03:00
Темы: bsd hate systemd
Осилил 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 хорошо дисциплинирует и показывает огрехи подходов!
Сгенерирован: SGBlog 0.34.0