SEP Jan Feb 15 2007 2009 2010 9 captures 1 May 05 - 15 Jan 09

Close Help

На прошлой лекции мы с вами посмотрели каким образом может осуществляться планирование в операционной системе UNIX. Мы с вами определили, что в принципе планированию в системе поддаются два типа процессов. Первый тип — это те процессы, которые находятся в оперативной памяти и между которыми происходит разделение времени ЦП. Мы выяснили, что этот механизм достаточно прост и строится на вычислении некоторого значения приоритета. А что будет, если системная составляющая достигнет максимального значения? В этом случае у процесса просто будет низший приоритет. Второй тип процессов, процессы которые находятся на диске, поддается планированию свопинга. Любой процесс в системе может находиться в двух состояниях — либо он весь откачан на ВЗУ, либо он весь находится в оперативной памяти. И в том и в другом случае с процессом ассоциирована некоторое значение P_TIME, которое растет по мере нахождения процесса в том конкретном состоянии. Это значение обнуляется, когда процесс меняет свое состояние (то есть перекачивается в оперативную память или обратно). В свою очередь система использует P_TIME как значение некоторого приоритета (чем больше это значение, тем более вероятно, что процесс сменит свой статус).

Возникал вопрос, что является причиной для инициации действия по докачке процесса из области свопинга в оперативную память. Этот вопрос не имеет однозначного ответа, потому что в каждом UNIX-е это сделано по-своему. Есть два решения. Первое решение заключается в том, что при достижении P_TIME некоторого граничного значения, то операционная система начинает стараться его перекачать в оперативную память для дальнейшей обработки. Второе возможное решение может состоять в том, что имеется некоторое условия на системную составляющую нулевого процесса (нулевой процесс — это ядро). Как только в системе возникает ситуация, что ядро в системе начинает работать очень много, то это становится признаком того что система недогружена, т.е. у системы может быть много процессов в оперативной памяти, но они все занимаются обменом, и ЦП простаивает. Система может в этой ситуации какие-то процессы откачать, а какие-то ввести в мультипрограммную обработку.

Мы с вами говорили о том, что разные UNIX-ы могут по-разному представлять процесс в ходе его обработки. Некоторые UNIX-ы представляют тело процесса как единое целое (и код и данные) и все перемещения осуществляются согласно тому, что это единое целое. Некоторые (современные) UNIX-ы рассматривают процесс как объединение двух сегментов — сегмента кода и сегмента данных. С этим связаны проблемы запуска процессов, планирования времени процессора и планирования свопинга.

При запуске какого-то процесса система должна понять, нет ли этого процесса уже в числе запущенных, чтобы не запускать лишний сегмент кода, а привязать новые данные к уже функционирующему сегменту кода. Это определяется достаточно просто — в контексте процесса есть параметр, который содержит значение ИД файла, из которого был запущен данный процесс. И когда система пытается загрузить новый процесс (из файла), то передэтим осуществляется просмотр контекстов существующих процессов и система смотрит, нет ли уже в оперативной памяти процесса с заданным ИД, т.е. процесса, запущенного из того же файла. Аналогично происходит учет при свопировании, т.е. сначала свопированию отдаются сегменты данных, а затем могут рассматриваться кодовые сегменты. Обращаю внимание, что при выполнении функции exec в контексте процесса сменится соответствующая информация (информация об ИД).

Напоминаю, что цель нашего курса не есть изучение того, как реализована та или иная функция в той или иной версии системы UNIX. Мы хотим посмотреть, как это можно сделать, чтобы у вас не было представления чуда, когда вы видите работающую операционную систему и вас пробирает дрожь, что это что-то от всевышнего.Все предельно просто. Есть правило, что чем более системной является программа, тем более прозрачными должны быть алгоритмы и использованные идеи. Мудреные программы живут с трудом, и это подтверждено практикой. Прозрачные программы живут долго. Пример — UNIX — прозрачная программа, и пример Windows — программа, построенная на очень высоком уровне, но там нет прозрачности на всех уровнях, и к сожалению система имеет достаточное количество особенностей, которые приводят к непредсказуемым результатам ее работы. Так везде. Если мы посмотрим языки программирования — был совершенно фантастический проект языка АДА, когда на конкурсной основе были образованы несколько профессиональных команд, которые разрабатывали язык конца XX века. Он должен был уметь делать все. Получилась очень красивая вещь. С профессиональной точки зрения этот язык во всем хорош, но он не нашел практического применения, потому что сложен. Совершенно “бездарный” язык Си существует и еще долго будет существовать. То же самое можно сказать о языках Вирта (это дядя, который придумал Паскаль, Модулу и Оберон), они тоже не прижились.

С этого момента времени мы начинаем долго и упорно рассматривать различные способы взаимодействия процессов в операционной системе UNIX. Маленькое техническое добавление. Я сейчас вам продекларирую две системные функции, которыми мы будем пользоваться впоследствии. Это функции дублирования файловых дескрипторов (ФД).

Аргументом функции dup является файловый дескриптор открытого в данном процессе файла. Эта функция возвращает -1 в том случае если обращение не проработало, и значение больше либо равное нулю если работа функции успешно завершилась. Работа функции заключается в том, что осуществляется дублирование ФД в некоторый свободный ФД. Т.е. можно как бы продублировать открытый файл.

Функция dup2 дублирует файловый дескриптор fd в некоторый файловый дескриптор с номером to_fd. При этом, если при обращении к этой функции ФД в который мы хотим дублировать был занят, то происходит закрытие файла, работающего с этим ФД, и переопределение ФД.

Пример:

Программа открывает файл с именем a.txt только на чтение. ФД который будет связан с этим файлом, находится в fd. Далее программа обращается к функции dup2, в результате чего будет заменен стандартный ввод процесса на работу с файлом a.txt. Далее можно закрыть дескриптор fd. Функция gets прочтет очередную строку из файла a.txt. Вы видите, что переопределение осуществляется очень просто.

Программные каналы.

Сначала несколько слов о концепции. Есть два процесса, и мы хотим организовать взаимодействие между этими процессами путем передачи данных от одного процесса к другому. В системе UNIX для этой цели используются т.н. каналы. С точки зрения программы, канал есть некая сущность, обладающая двумя файловыми дескрипторами. Через один ФД процесс может писать информацию в канал, через другой ФД процесс может читать информацию из канала. Так как канал это нечто, связанное с файловыми дескрипторами, то канал может передаваться по наследству сыновним процессам. Это означает, что два родственных процесса могут обладать одним и тем же каналом. Это означает, чтоесли один процесс запишет какую-то информацию в канал, то другой процесс может прочесть эту информацию из этого же канала.

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

Давайте посмотрим, как эти концепции реализуются в системе. Есть функция pipe. Аргументом этой функции должен быть указатель на массив двух целых переменных.

Нулевой элемент массива после обращения к функции pipe получает ФД для чтения, первый элемент этого массива получает ФД для записи. Если нет свободных ФД, то эта функция возвращает -1. Признак конца файла для считывающего дескриптора не будет получен до тех пор, пока не закрыты все дескрипторы, связанные с записью в этот канал. Рассмотрим небольшой пример:

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

pipe(fd); /* в отцовском процессе образуем два дескриптора канала */

if (fork()) /* образуем процесс-сын у которого будут те же дескрипторы */

{ /* эта часть программы происходит в процессе-отце */

dup2(fd[1],1); /* заменяем стандартный вывод выводом в канал */

close(fd[1]); /* закрываем дескрипторы канала */

close(fd[0]); /* теперь весь вывод итак будет происходить в канал */

execl(“/bin/ls”,“ls”,(char*)0); /* заменяем тело отца на ls */

} /* отсюда начинает работать процесс-сын */

dup2(fd[0],0); /* в процессе сыне все делаем аналогично */

Этот пример связывает конвейером две команды — ls и wc. Команда ls выводит содержимое каталога, а команда wc подсчитывает количество строк. Результатом выполнения нашей программы будет подсчет строк, выведенных командой ls.

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

Мы говорили о том, что для того, чтобы канал работал корректно, и читающий дескриптор получил признак конца файла, должны быть закрыты все пишущие дескрипторы. Если бы в нашей программе не была бы указана выделенная строка, то процесс, связанный с wc завис бы, потому что в этом случае функция, читающая из канала, не дождется признака конца файла. Она будет ожидать его бесконечно долго. В процессе отце подчеркнутую строку можно было бы не указывать, т.к. дескриптор закрылся бы при завершении процесса, а в процессе сыне такая строка нужна. Т.е. вывод таков, что перед завершением работы должны закрываться все дескрипторы каналов, связанные с записью.

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

Сигналы

Рассмотрим взаимодействие между процессами с помощью приема-передачи сигналов. Мы уже говорили о том, что в системе 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.

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

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

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

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 могут не совпадать. Для этого следует посмотреть мануалы и, если надо, подправить программы.

Трассировка

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

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 <stdio.h>

#include <unistd.h>

#include <signal.h>

#include <sys/types.h>

#include <sys/ptrace.h>

#include <sys/wait.h>

#include <machine/reg.h>

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) &REGS, 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, которая продолжит выполнение трассируемого процесса. На второй итерации мы попадем на событие деления на ноль. Таким образом, мы получим две порции информации — первая связана с самой первой приостановкой сыновнего процесса, когда заменяется его тело, а вторая — связана с делением на ноль.