После чтения теории, моделирования схем в симуляторах пришла пора попробовать свои силы на реальном примере. А так как сейчас без микроконтроллеров не обойтись, решил собрать программатор.

Имею, 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, прописать структуру, а так как в массив нужно сохранять разнородные данные, для простоты читабельности кода, пришлось для каждого параметра делать отдельный массив.

Читать далее...

Я сразу приведу список статей на которые опирался, при проведении дальнейших экпериментов:

  1. Using System Tap to test the GNU C Library
  2. Стандартные утилиты для UNIX-программиста

Список макроопределений 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

Продолжу...

Читать далее...