Главная страница

Лекции Системное ПО. Лекция Структура и основные компоненты вычислительной системы


Скачать 0.71 Mb.
НазваниеЛекция Структура и основные компоненты вычислительной системы
Дата13.09.2022
Размер0.71 Mb.
Формат файлаdoc
Имя файлаЛекции Системное ПО.doc
ТипЛекция
#675338
страница10 из 15
1   ...   7   8   9   10   11   12   13   14   15

Лекция 14

 

Сигналы

Рассмотрим взаимодействие между процессами с помощью приема-передачи сигналов. Мы уже говорили о том, что в системе Unix можно построить аналогию механизму прерываний из некоторых событий, которые могут возникать при работе процессов.

Эти события, также как прерывания, однозначно определены для конкретной версии ОС. То есть определен набор сигналов. Возникновение сигналов, почти также как и возникновение прерываний может происходить по следующим причинам:

    • некоторое событие внутри программы, например, деление на ноль или переполнение;

    • событие, связанное с приходом некоторой информации от устройства, например, событие, связанное с передачей от клавиатуры комбинации “Ctrl+C”;

    • событие, связанное с воздействием одного процесса на другой, например, “sig_kill”.

Система имеет фиксированный набор событий, которые могут возникать. Каждое событие имеет свое уникальное имя, эти имена обычно едины для всех версий Unix. Такие имена называются сигналами.

Перечень сигналов находится в include-файле “signal.h”.

Есть сигналы, которые присутствуют практически во всех Unix, но также есть сигналы, специфичные лишь для конкретной версии Unix (FreeBSD, SCO Unix, Linux, ...) Например, в версии BSD есть сигнал приостановки работы процесса, реакцией на него является замораживание процесса, а есть сигнал, который размораживает процесс. Это сигнал FreeBSD версии.

Прототип функции обработки сигнала:

void (* signal (sig, fun)) ()

int sig;

void (* fun) ();

При обращении к signal мы передаем:

sig — имя сигнала;

fun — указатель на функцию, которая будет обрабатывать событие, связанное с возникновением этого сигнала. Она возвращает указатель на предыдущую функцию обработки данного сигнала.

Мы говорили о том, что событие, связанное с возникновением сигнала может быть обработано в системе тремя способами:

    1. SIG_DEF — стандартная реакция на сигнал, которая предусмотрена системой;

    2. SIG_IGN — игнорирование сигнала (следует отметить, что далеко не все сигналы можно игнорировать, например, SIG_KILL);

    3. Некоторая пользовательская функция обработки сигнала.

Соответственно, указывая либо имена предопределенных констант, либо указатель на функцию, которую мы хотим определить, как функцию-обработчик сигнала, можно предопределить реакцию на тот или иной сигнал. Установка обработки сигнала происходит одноразово, это означает то, что если мы установили некоторую обработку, то по этому правилу будет обработано только одно событие, связанное с появлением данного сигнала. И при приходе в функцию обработчика устанавливается стандартная реакция на сигнал. Возврат из функции-обработчика происходит в точку прерывания процесса.

Приведем пример программы “Будильник”. Средствами ОС мы будем “заводить” будильник. Функция alrm инициализирует появление сигнала SIG_ALRM.

 

main ()

{ char s[80];

signal(SIG_ALRM, alrm); /* установка режима связи с событием SIG_ALRM на функцию alrm */

alarm(5); /* заводим будильник */

printf(“Введите имя \n”);

for (;;) {

printf(“имя:”);

if (gets(s,80) != NULL) break;

};

printf(“OK! \n”);

}

alrm () {

printf(“\n жду имя \n”);

alarm(5);

signal (SIG_ALRM,alrm);

}

В начале программы мы устанавливаем реакцию на сигнал SIG_ALRM на функцию alrm, далее мы заводим будильник, запрашиваем “Введите имя” и ожидаем ввода строки символов. Если ввод строки задерживается, то будет вызвана функция alrm, которая напомнит, что программа “ждет имя”, опять заведет будильник и поставит себя на обработку сигнала SIG_ALRM еще раз. И так будет до тех пор, пока не будет введена строка.

Здесь имеется один нюанс: если в момент выполнения системного вызова возникает событие, связанное с сигналом, то система прерывает выполнение системного вызова и возвращает код ответа, равный “-1”. Это мы можем также проанализировать по функции errno.

Надо отметить, что одноразово устанавливается только “свой” обработчик. Дефолтный обработчик или игнорирование устанавливается многоразово, то есть его не надо каждый раз подтверждать после обработки сигнала.

Еще две функции, которые необходимы нам для организации взаимодействия между процессами:

int kill(int pid, sig) — это функция передачи сигнала процессу. Она работает следующим образом: процессу с номером pid осуществляется попытка передачи сигнала, значение которого равно sig. Соответственно, сигнал может быть передан в рамках процессов, принадлежащих одной группе. Код ответа: -1, если сигнал передать не удалось, пояснение опять же можно найти в errno. Функция kill может использоваться для проверки существования процесса с заданным идентификатором. Если функция выполняется с sig=0, то это тестовый сигнал, который определяет — можно или нетпередать процессу сигнал, если можно, то код ответа kill отличен от “-1”. Если pid=0, то заданный сигнал передается всем процессам, входящим в группу.

int wait(int *wait_ret). Ожидание события в сыновнем процессе. Если сыновнего процесса нету, то управление возвращается сразу же с кодом ответа “-1” и расшифровкой в errno. Если в процессе-сыне возникло событие, то анализируются младшие 16 бит в значении wait_ret:

Если сын приостановлен (трассировка или получение сигнала), тогда старшие 8 бит wait_ret — код сигнала, который получил процесс-сын, а младшие содержат код 0177.

Если сыновий процесс успешно завершился через обращение к функции exit. Тогда младшие 8 бит равны нулю, а старшие 8 бит равны коду, установленному функцией exit.

Если сын завершился из-за возникновения у него необрабатываемого сигнала, то старшие 8 бит равны нулю, а младшие — номер сигнала, который завершил процесс.

Функция wait возвращает идентификатор процесса в случае успешного выполнения и “-1” в противном случае. Если одно из перечисленных событий произошло до обращения к функции, то результат возвращается сразу же, то есть никакого ожидания не происходит, это говорит о том, что информация о событиях в процессе безвозвратно не теряется.

Давайте рассмотрим еще один пример. Наш будильник будет уже многопроцессный.

alr() { printf(“\n Быстрее!!! \n”);

signal (SIG_ALRM, alr);

}

main () { char s[80; int pid;

signal(SIG_ALRM, alr);

if (pid=fork()) for (;;)

{sleep(5); kill(pid, SIG_ALRM);}; /* приостанавливаем процесс на 5 секунд и отправляем сигнал SIG_ALRM процессу сыну */

print(“имя?”);

for (;;) {printf(“имя?”);

if gets(s,80)!=NULL) break;

}

printf(“OK!\n”);

kill(getpid(), SIG_KILL); /* убиваем зациклившегося отца */

}

Следует заметить, что в разных версиях Unix имена сигналов могут различаться.

Наша программа реализуется в двух процессах.

Как и в предыдущем примере имеется функция реакции на сигнал alr(), которая выводит на экран надпись и переустанавливает функцию реакции на сигнал опять же на себя. В основной программе мы также указываем alr(), как реакцию на SIG_ALRM. После этого мы запускаем сыновий процесс, и в отцовский процесс (бесконечный цикл) “засыпает” на 5 единиц времени, после чего сыновнему процессу будет отправленсигнал SIG_ALRM. Все, что ниже цикла будет выполняться в процессе-сыне: мы ожидаем ввода строки, если ввод осуществлен, то происходит убиение отца (SIG_KILL).

Таким образом, мы описали базовые средства взаимодействия процессов в Unix: порождение процесса, замена тела процесса, взаимодействие при помощи передач/приемов сигналов.

Замечание: мы говорим о некотором обобщенном Unix, реальные Unix’ы могут иметь некоторые отличия друг от друга. На сегодняшний день имеются достаточно формализованные стандарты на интерфейсы ОС, в частности Unix. Это POSIX-standard, то есть были проведены работы по стандартизации интерфейсов всех уровней для открытых систем. Основной задачей является унификация работы с системами, как на уровне запросов от пользователя, так и на уровне системных вызовов. В принципе, на сегодняшний день практически все разработчики ОС стараются привести свои системы к стандарту POSIX. В частности, Microsoft объявила, что системные вызовы и работа с файлами в Windows NT происходит в стандарте POSIX. Но так или иначе реальные коммерческие системы от этого стандарта отходят.

Второе замечание: мы начали рассматривать примеры, но крайне важно, чтобы все эти примеры были реализованы на практике, дабы убедиться, что они работают, посмотреть как они работают и добиться этой работы, так как версии Unix могут не совпадать. Для этого следует посмотреть мануалы и, если надо, подправить программы.


Лекция 15

 

Трассировка

Трассировка — это возможность одного процесса управлять кодом и выполнением другого процесса.

Давайте для начала посмотрим на действия, которые выполняются при отладке:

    1. Установка контрольной точки;

    2. Обработка ситуации, связанной с приходом в контрольную точку;

    3. Чтение/запись информации в отлаживаемой программе;

    4. Остановка/продолжение выполнения отлаживаемого процесса;

    5. Шаговый режим отладки (режим, при котором отлаживаемая программа будет останавливаться после выполнения каждой инструкции);

    6. Передача управления на произвольную точку отлаживаемой программы;

    7. Обработка аварийных остановок;

Это семь позиций, которые реализуются почти в любом средстве отладки с точностью до добавленных или удаленных возможностей будь-то Windows 95/NT, Unix, OS/2, DOS и т.д. Есть некоторый джентельментский набор, который обычно предоставляет отладчик. Теперь посмотрим,какими средствами можно организовать выполнение этих функций в ОС Unix.

Итак, есть функция, которая называется

int ptrace(int op, pid, addr, data)

Суть этой функции заключается в следующем: ptrace в подавляющем большинстве случаев работает в отцовском процессе, и через возможности ptrace организуется управление сыном. В общем случае нельзя трассировать любой процесс. Для того, чтобы процесс можно было отлаживать, процесс-сын должен подтвердить согласие на собственную трассировку, в последнем случае следует в самом начале выполнения вызвать ptrace с кодом операции равном нулю (op=0), этот вызов разрешает в дальнейшем трассироваться процессом-отцом. После этого в сыновнем процессе обращений к ptrace может и не быть.

Посмотрим, какие возможности есть у отцовского процесса по управлению процессом-сыном. Для начала разберем параметры функции ptrace:

op — код операции;

pid — PID сыновнего процесса;

addr — некоторый адрес внутри сыновнего процесса (будет объяснено при описании параметра op);

data — слово информации;

op

addr

data

 

0

 

 

Разрешение на трассировку себя

1,2

 

 

ptrace возвращает слово, расположенное по адресу, заданному в параметре addr. Это есть чтение по адресу. (Два значения задается из-за того, что в рамках процесса может быть двойная адресация — по коду и по данным)

3

 

 

Чтение из контекста процесса. Обычно речь идет о доступе к информации из контекста, сгруппированной в некоторую структуру. И в этом случае параметр addr указывает на смещение внутри данной структуры. В структуре мы можем найти регистры, текущее состояние процесса, счетчик адреса и т.д. Этот набор немного варьируется от системы к системе.

4,5

 

 

Запись данных, расположенных в data по адресу addr. Этот параметр также двойной по причине возможного разделения кода и данных процесса. Если происходит ошибка, то ptrace возвращает “-1” (уточнение ошибки в errno)

6

 

 

Запись данных из data в контекст процесса. Роль addr такая же, как и при op=3. То есть мы можем изменить регистры трассируемого процесса, в том числе регистр счетчика команд (сделать переход внутри процесса).

7

 

 

Продолжение выполнения трассируемого процесса. Тут есть некоторые тонкости. Если трассируемый процесс был по какой-то причине остановлен. Пока он стоит к нему могут прийти какие-то сигналы от других процессов. Что делать, когда к остановленному процессу пришли сигналы? Здесь играют роль параметры data и addr.

 

 

0

Процесс, который был приостановлен, продолжит свое выполнение и при этом все пришедшие и необработанные сигналы будут проигнорированы.

 

 

N_SIG

Будет смоделирирована ситуация прихода сигнала с заданным номером N_SIG. Все остальные сигналы будут проигнорированы.

 

=1

 

Сыновний процесс продолжает выполняться с места, в котором он был приостановлен.

 

>1

 

Происходит переход по адресу (абсолютному адресу) на addr внутри процесса. (goto addr)

8

 

 

Завершение трассируемого процесса.

9

 

 

Установка бита трассировки. Этот бит позволяет делать пошаговое выполнение команд. После выполнения каждого машинного кода происходит реакция на сигнал SIG_TRAP.

Мы рассмотрели функцию ptrace в некоторой модельной нотации. Модельная нотация заключается в том, что в разных системах эта функция может иметь несколько другую интерфейсную часть (одни константы op могут быть присутствовать, другие отсутствовать или иметь другой номер, отличается доступ к контексту процесса и т.п.)

Все действия, о которых мы говорили, выполняются при остановленном сыновнем процессе (он может быть остановлен из-за ошибки (деление на ноль, например), прихода сигнала от отца или другого процесса и т.п.) Для того, чтобы процесс-отец мог остановить сына, то он должен выполнить следующие действия:

    1. Послать сыну сигнал SIG_TRAP;

    2. Выполнить wait;

    3. После того, как сын остановился, отец получает соответствующий код ответа от функции wait.

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

Установка контрольной точки. Считается, что в отладчике имеется некоторая таблица, которая содержит информацию о контрольных точках внутри отлаживаемого процесса:

Номер контрольной точки

Адрес контрольной точки

Сохраненное слово

Счетчик

...

...

_...

...

Что происходит при установке контрольной точки? При запросе на установку контрольной точки по заданному адресу отладчик читает содержимое отлаживаемого процесса по этому адресу и записывает это содержимое в таблицу (Сохраненное слово). Затем, отладчик по указанному адресу записывает машинную команду, которая вызовет возникновение события, связанного с некоторым сигналом (например, команда деления на ноль, вызов программного прерывания или любая команда, вызывающая событие, которое должно быть известно), после этого мы можем запустить отлаживаемый процесс (ptrace, op=7). В тот момент, когда управление придет на адрес, где мы установили контрольную точку, произойдет прерывание процесса и событие, связанное с известной установкой. Для отладчика это будет видно следующим образом — после запуска на продолжение отлаживаемого процесса выполняется функция wait, которая ожидает события в отлаживаемом процессе. Событие произошло, его причиной был некоторый сигнал. Действия отладчика:

    1. Не совпадает ли сигнал, который прервал процесс с сигналом, который является контрольным сигналом. Если не совпадает, то произошла какая-то ситуация, которая обрабатывается по-своему. Если же совпадает, то мы, скорее всего, попали на контрольную точку (предположим, что у нас это сигнал деления на ноль).

    2. После этого мы читаем из контекста процесса точку останова — если она совпала с одной из позиций таблицы отладчика, то это означает, что мы совершенно точно попали на контрольную точку. Если такого совпадения не обнаружено, то это означает, что тревога ошибочна и обработка сигнала уходит по другому направлению.

    3. Если все-таки мы оказались на контрольной точке, то можем выполнить какие-то действия над отлаживаемым процессом (чтение/запись регистров, ячеек памяти и прочее).

    4. Наконец, нам хочется продолжить выполнение программы, но при этом мы бы хотели сохранить контрольную точку. Что может сделать отладчик? Он восстанавливает оригинальное содержимое машинного слова. Включает режим трассировки и запускает программу с прерванного адреса. После чего выполняется команда, которую мы восстановили и процесс приостанавливается (так как включена трассировка) на следующей команде. Теперь мы опять по нужному адресу пишем команду деления на ноль и продолжаем процесс уже вне режима трассировки. Таким образом мы восстановили контрольную точку.

Снятие контрольной точки происходит тривиально — восстанавливается содержимое по соответствующему адресу и строка данной точки выбрасывается из таблицы.

Контрольные точки могут устанавливаться на какое-то количество прохождений — в таблицу включается позиция счетчика, куда вносится какое-то число, и при каждом прохождении через данную контрольную точку из счетчика будет вычитаться единица, а по достижении нуля точка будет снята.

Итак, мы обсудили с точностью до некоторых деталей структуру адресного отладчика.

Если возникает необходимость символьной отладки (отладки в терминах языка высокого уровня), то добавляются некоторые средства, позволяющие определять адреса и свойства переменных и адреса операторов. В этом случае, например, команда чтения языковой переменной программы будет осуществляться следующим образом: если надо найти переменную с именем name, то отладчик ищет ее в таблице, проверяет области видимости и смотрит ее атрибуты. Если переменная статическая, то выбирается ее адрес, и мы обращаемся через ptrace к соответствующей адресной ячейке. Если переменная автоматическая, то через соответствующее смещение относительно стека, мы, читая из контекста вершину стека и прибавляя смещение, читаем нужную переменную. Если переменная регистровая, то в таблице содержится номер регистра, на котором она размещена, соответственно, для ее чтения нам достаточно прочитать из контекста соответствующий регистр.Для изменения содержимого переменных используется этот же аппарат.

Приведем небольшой пример трассировки:

Процесс-сын:

int main()

{ int i;

return i/0;

}

Процесс отец:

(Мы будем писать программу в нотации ОС FreeBSD)

#include

#include

#include

#include

#include

#include

#include

int main(int argc; char *argv[])

{ pid_t pid;

int status;

struct reg REG;

switch (pid=fork()) {

case -1: perror(“ошибка fork”); exit(); /* ошибка создания сына */

case 0: ptrace(PT_TRACE_ME,0,0,0); /* если в сыне, то разрешаем трассировку */

execl(“son”,”son”,0); /* и замещаем тело процесса */

/* после входа в сына, процесс-сын будет остановлен с сигналом SIG_TRAP, это правила игры — как только отлаживаемый процесс меняет тело, то происходит приостановка в самом начале */

default: break; /* если в отце, то выходим из switch */

}

/* в отце */

for (;;) {

wait(&status); /* ждем, когда отлаживаемый процесс приостановится (первый раз это произойдет сразу после замены тела сыновнего процесса), то есть, когда в нем возникнет событие */

ptrace(PT_GET_REGS,pid, (caddr_t) ®S, 0); /* теперь мы можем прочесть и вывести содержимое некоторых регистров */

printf(“EIP=%O.8X\+ESP=%O.8X\n”, REG.r_eip, REG.r_esp);

if (WIFSTOPPED(status) || WIFSIGNALED(status)) {

/* Выше написанные макросы описаны в файлах include, они обрабатывают структуру, возвращаемую функцией wait, если у нас условия приостановки нормальные, то начинаем разбирать причину */

printf(“сигнал:”);

switch(WSTOPSIG(status)) {

case SIGINT: printf(“INT\n”); break;

case SIGTRAP: ...

...

defalt: printf(“%d”, WSTOPSIG(status));

};

if (WSTOPSIG(status)!=SIGTRAP) exit(1);

};

if (WIFEXITED(status)) { /* если отлаживаемый процесс завершился */

printf(“процесс закончен с кодом = %d\n”, WEXITSTATUS(status));

exit};

ptrace (PT_CONTINUE, pid, (caddr_t) 1, 0); /* продолжаем выполнение трассируемого процесса */

}

exit(0);

}

При первой итерации бесконечного цикла мы остановимся при получении сыном сигнала SIG_TRAP, посмотрим, не закончился ли наш процесс нормально (а он нормально закончиться не может, так как делит на ноль), то мы обратимся к ptrace, которая продолжит выполнение трассируемого процесса. На второй итерации мы попадем на событие деления на ноль. Таким образом, мы получим две порции информации — первая связана с самой первой приостановкой сыновнего процесса, когда заменяется его тело, а вторая — связана с делением на ноль.
1   ...   7   8   9   10   11   12   13   14   15


написать администратору сайта