После чтения теории, моделирования схем в симуляторах пришла пора попробовать свои силы на реальном примере. А так как сейчас без микроконтроллеров не обойтись, решил собрать программатор.
Имею, Arduino UNO, кстати, впервые приобретенное именно в амперке в рамках набора Матрешка Z. Ибо каждый раз покупать плату ардуино, если придет в голову очередная гениальная -сумасшедьшая идея сваять что-то на контроллере дороговато, зато купить просто Attiny или Atmega8 проще. Следовательно нужен прогррамматор. А чем ардуино не программатор?
Самую годную схему я нашел здесь. Я, как и автор статьи, оказался жмотом(да и самому поковыряться было интересно) и решил сделать сам. Вот как выглядит схема от автора:
В этой статье не планирую ставить никакого задания. Просто буду собирать полезные сценарии из интернета и возможно - описывать свои. А так же вставлю ссылки на полезные статьи по исследованию и описанию работы некоторых функций glibc, для дальнейшей возможности обследования их через systemtap.
Сценарий 1
Интересный скрипт, позволяющий остановить выполнение программы в нужном месте и запустить gdb
Попробую написать утилитку, которая бы отслеживала путь выполнения программы, не так подробно как ltrace, но все же существенно более быстро.
А так же попробую воспользоваться функциями.
1 Напишу функцию, которая аналогична indent, но с собственным алгоритмом формирования смещения:
function local_depth() {
ind = ""
for (i=depth[tid()];i>=0;i--){
ind = sprintf("%s|", ind)
}
ind = ind . ">"
return ind
}Результат выполения функции - это строка отступа для текущего потока с учетом глубины вложенности. Т.е сведения о глубине хранятся в массиве depth с ключем tid(), т.е идентификатором текущего потока. Результат примерно выглядит так |||> или |||||||>
Задача для проба: написать пробы которые бы отслеживали посланный от процесса к процессу сигнал в CentOS 7, вывод обеспечит в двух строках: 1 - кто послал кому послал и какой сигнал, 2 - кто принял. И вывод бактрейса хендлера принявшего сигнал.
Первым делом я посетил вот этот перечень готовых функций: https://sourceware.org/systemtap/tapsets/signal.stp.html
Он содержит все необходимы для реализации программы функции: signal.send+ и signal.handle+
Учитывая, что необходимо один раз выводить информацию и о посылавшем процессе и о принимающем, то сохраним при посылке данные в массив. Вот тут я и наткнулся на необычное для меня поведение программы, отсутствие поддержки локалных массивов. Это очень неудобно. Второй момент, что-то я не нашел варианта кроме embedded C, прописать структуру, а так как в массив нужно сохранять разнородные данные, для простоты читабельности кода, пришлось для каждого параметра делать отдельный массив.
Я сразу приведу список статей на которые опирался, при проведении дальнейших экпериментов:
Список макроопределений systemtap:
| Название | Описание |
|---|---|
| $$vars | Expands to a character string that is equivalent to sprintf("parm1=%x ... parmN=%x var1=%x ... varN=%x", parm1, ..., parmN, var1, ..., varN) for each variable in scope at the probe point. Some values may be printed as “=?” if their run-time location cannot be found. |
| $$locals | Expands to a subset of $$vars containing only the local variables. |
| $$parms | Expands to a subset of $$vars containing only the function parameters. |
| $$return | Is available in return probes only. It expands to a string that is equivalent to sprintf("return=%x", $return) if the probed function has a return value, or else an empty string |
Продолжу...
AlexBR
Обо мне
bayrepo.info@gmail.com, все!
Репозиторий с полезными пакетами(по моему мнению):
CentOS 9
есть самописные программы и библиотеки описанные в блоге и документации, а так же последние версии используемых мною программ.
Отладчики, дизассемблеры, статические анализаторы
Блог удач и неудач. Здесь я выкладываю статьи о начинаниях которые получились и которые не получались.
youtube канал
rutube канал