API tools faq
paste
Ladies_Man

course-compilers-tex

Ladies_Man
Feb 25th, 2017
168
0
Never
Add comment
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
Latex 93.87 KB | None | 0 0
raw download clone embed print report
  1. \documentclass[12pt]{article}
  2. % Эта строка — комментарий, она не будет показана в выходном файле
  3. \usepackage{ucs}
  4. \usepackage[utf8]{inputenc} % Включаем поддержку UTF8
  5. \usepackage[russian]{babel}  % Включаем пакет для поддержки русского языка
  6. \title{Databases Course Project}
  7. \date{}
  8. \author{Anthony Belyaev}
  9.  
  10. \usepackage{geometry} % А4, примерно 28-31 строк(а) на странице   
  11.     \geometry{paper=a4paper}
  12.    \geometry{includehead=false} % Нет верх. колонтитула
  13.     \geometry{includefoot=true}  % Есть номер страницы
  14.     \geometry{bindingoffset=0mm} % Переплет    : 0  мм
  15.     \geometry{top=20mm}          % Поле верхнее: 20 мм
  16.     \geometry{bottom=25mm}       % Поле нижнее : 25 мм
  17.     \geometry{left=25mm}         % Поле левое  : 25 мм
  18.     \geometry{right=25mm}        % Поле правое : 25 мм
  19.     \geometry{headsep=10mm}  % От края до верх. колонтитула: 10 мм
  20.     \geometry{footskip=20mm} % От края до нижн. колонтитула: 20 мм
  21.    
  22. \usepackage{amsmath}    % \bar    (матрицы и проч. ...)
  23. \usepackage{amsfonts}   % \mathbb (символ для множества действительных чисел и проч. ...)
  24. \usepackage{mathtools}  % \abs, \norm
  25.     \DeclarePairedDelimiter\abs{\lvert}{\rvert}
  26.    \DeclarePairedDelimiter\norm{\lVert}{\rVert}
  27.  
  28. \usepackage{textcomp} %arrows      
  29.    
  30. \usepackage{listings} %листинги
  31.  
  32. \lstset{
  33.  basicstyle=\ttfamily,
  34.  columns=fullflexible,
  35.  keepspaces=true,
  36.  frame=top,frame=bottom,
  37. }
  38.  
  39. \usepackage[table,xcdraw]{xcolor}
  40.  
  41. \usepackage{graphicx} %package to manage images
  42. \graphicspath{ {img/} }
  43.  
  44. \begin{document}
  45.  
  46. \begin{titlepage}
  47. \newpage
  48.  
  49. \begin{center}
  50. \begin{footnotesize}
  51. \textit{Федеральное государственное бюджетное образовательное учреждение \\ высшего профессионального образования} \\
  52. \vspace{0.7cm}
  53. \textbf{Московский государственный технический университет имени Н.Э. Баумана \\ (МГТУ им. Н.Э. Баумана)} \\
  54. \vspace{0.7cm}
  55. Факультет: <<Информатика и системы управления>> \\
  56. Кафедра: <<Теоретическая информатика и компьютерные технологии>> \\
  57. \end{footnotesize}
  58. \end{center}
  59.  
  60. \hrulefill
  61.  
  62. \vspace{\fill}
  63.  
  64. \begin{figure}[htbp]
  65.  \centering
  66.  \includegraphics[width=0.15\textwidth]{bmstulogo}
  67.  \label{fig:bmstu_logo}
  68. \end{figure}
  69.  
  70. \vspace{\fill}
  71.  
  72. \begin{center}
  73. \Large Расчетно-пояснительная записка \\ к курсовому проекту  по дисциплине \\ «Конструирование компиляторов»
  74. \end{center}
  75.  
  76. \vspace{1em}
  77.  
  78. \begin{center}
  79. \textsc{\textbf{Портирование компилятора BeRo TinyPascal \\
  80.                 на платформу Linux x64}}
  81. \end{center}
  82.  
  83. \vspace{2em}
  84. \begin{center}
  85. \begin{tabular}{ r c l }
  86.     Руководитель курсового проекта: & \underline{\hspace{4cm}} & (А. В. Коновалов) \\ & (подпись, дата) & \\ \\
  87.     Исполнитель курсового проекта,\\студент группы ИУ9-72: & \underline{\hspace{4cm}} & (А. В. Беляев) \\ & (подпись, дата) & \\ \\
  88. \end{tabular}
  89. \end{center}
  90.  
  91. \vspace{3em}
  92.  
  93. \begin{center}
  94. Москва, 2017
  95. \end{center}
  96.  
  97. \end{titlepage}
  98.  
  99.  
  100.     \newpage
  101.     {
  102.         \tableofcontents
  103.         \clearpage
  104.     }
  105.    
  106.    
  107.    
  108.    
  109.    {
  110.        \section{ВВЕДЕНИЕ}
  111.    }
  112.    
  113.     Основная цель данной работы --- портирование компилятора языка Pascal, BeRo TinyPascal на ОС Linux, используемого на кафедре ИУ9 для проведения лабраторных работ по курсу конструирования компиляторов. Исходный компилятор работает на платформе Windows 32-х битной разрядности. В процессе портирования необходимо увеличить разрядность до 64 бит.
  114.    
  115.     В ходе работы будет исследовано устройство исполняемых файлов ОС Windows, исходной платформы компилятора, а также ОС Linux, целевой платформы и произведено их сравнение. Будет исследована архитектура существующего компилятора и особенности его реализации в ОС Windows. Затем будет произведена попытка обеспечить подобную архитектуру в ОС Linux.
  116.    
  117.     Далее будет произведен непосредственно портирование компилятора, изучены последствия переноса и будет произведено его тестирование на новой платформе.
  118.    
  119.    \clearpage
  120.    
  121.    
  122.    
  123.    
  124.    
  125.         {
  126.             \section{ОБЗОР ФОРМАТОВ ИСПОЛНЯЕМЫХ ФАЙЛОВ}
  127.     }
  128.    
  129.     Прежде всего стоит рассмотреть устройство исполняемых файлов. Исполняемый файл(Executable file) представляет из себя программу в таком виде, в котором она может быть загружена в память и после этого исполнена. Перед исполнением могут быть также выполнены некоторые подготовительные операции, например, загрузка динамических библиотек и настройка окружения. Программа несет в себе решение определенной задачи, что влияет на ее внутреннее устройство.
  130.  
  131.     Внутри файла данные хранятся в определенном формате, который разделяет их на несколько составляющих частей. Общими для большинства форматов частями являются {\it заголовки, инструкции} и {\it метаданные}.
  132.    
  133.     Заголовки представляют из себя структуры, определяющие, что именно находится в определенной части файла, как данные из этой части должны быть интерпретированы, как они должны быть исполнены и так далее. Более формально, в заголовках могут быть указаны параметры окружения, исполнители инструкций, настройки этих исполнителей, а также формат инструкций и данных. Исполнителями в данном случае могут являться конкретные процессоры конкретной архитектуры (например, Intel 80386, i486 от Intel или Am386, Am486 от AMD архитектуры x86), микроконтроллеры, интерпретаторы, как программные, так и аппаратные. Также известными исполнителями являются всевозможные виртуальные машины, начиная от JVM, CPython, .NET и вполть до VirtualBox и VMware. В рамках данной работы целевыми исполнителями будут процессоры архитектуры x86\_64.
  134.    
  135.     Часть исполняемого файла с инструкциями может содержать как машинные инструкции, так и исходный код, или же байт-код виртуальной машины.
  136.  
  137.     Существуют и другие части файла, разнящиеся от формата к формату. Так, кроме заголовков и инструкций в файле могут присутствовать данные для загрузчика файла в память, данные для отладки, таблицы симоволов, константы, описание окружения, на котором подразумевается исполнение файла, а также всяческие изображения, тексты, архивы, иконки ярлыков и любые другие данные.
  138.    
  139.     Так как описанные выше части файла и их наполнение рознятся от формата к формату, существует привязка файлов к конкретным исполнителям, например файлы только для вирутальной машины Java. Наличие вызовов библиотечных функций связывает файл с конкретной  библиотекой, которая в свою очередь может связывать его с определенным ядром ОС, набором модулей ОС и т.д.
  140.  
  141.     Среди наиболее популярных форматов файлов, которые будучи загруженными  соответствующим загрузчиком, могут быть непосредственно выполенены CPU, а не интерпретироваться специальным ПО, можно выделить --- PE (на Microsoft Windows), ELF (на Unix-подобных ОС), Mach-O (на OS X и iOS) и устаревший формат MZ (на DOS).
  142.    
  143.     Исходным форматом в рамках данной работы является PE формат (его 32-х битная версия, PE32). Целевым форматом является ELF. Далее они будут рассмотрены подробнее, так как значительная часть работы связана с обеспечением архитектуры Bero TinyPascal, аналогичной формату PE32 в рамках формата ELF.
  144.    
  145.    
  146.     \bigskip
  147.    
  148.     {
  149.         \subsection{Формат PE32}
  150.     }
  151.    
  152.     После того, как под ОС Windows написан код, подключены библиотеки и загружены ресурсы, все компонуется в единственный исполняемый файл формата .exe (для исполняемых файлов типов DLL и SYS также используется формат PE). Он содержит в себе всю информацию, необходимую PE-загрузчику для отображения файла в память.
  153.    
  154.     PE (Portable Executable, также известный, как PE/COFF) представляет из себя модифицированную под ОС Windows версию COFF формата Unix (не только Windows, но и ReactOS использует PE). С появлением Windows NT 3.1 в 1993 году Microsoft перешла на этот новый формат. Однако, для обратной совместимости с DOS-системами, формат сохранил ограниченную поддержку популярного на тот момент MZ. Так, формат PE на данный момент содержит в себе <<заглушку>> размером в 256 байт, в которую может быть записана мини версия программы размером в 192 байта и заголовок в 64 байта. Формат MZ на данный момент устарел и большинство программа содержат заглушку в виде вывода сообщения <<\verb|This program cannot be run in DOS mode|>>. Однако, формат PE32 уже начинает устаревать и появляются его расширения, например PE32+ (PE+) для x64, PE.NET.
  155.    
  156.     Перейдем непосредственно к техническим деталям формата. \cite{tour}. Для этого рассмотрим приблизительную схему его устройства.
  157.    
  158. \begin{figure}[h]
  159. \caption{Схематическое устройство PE}
  160. \centering
  161. \includegraphics[width=0.4\textwidth]{pe_small}
  162. \label{peSmall}
  163. \end{figure}
  164.  
  165.     Рассмторение начнем сверху-вниз. Начинается файл, согласно Рисунку \ref{peSmall}, с заголовков. Первым заголовком является упомянутый выше DOS заголовок (DOS header) длиной в 64 байта. Останавиваться на нем не имет смысла, так как интерес в нем представляют лишь первое и последнее поле - e\_magic и e\_lfanew. Первое представляет из себя 2 байта сигнатуры родительского формата -- 0x4D 0x5A -- <<MZ>>. Последнее поле -- по смещению 0x3C -- содержит адрес PE-заголовка (PE header), который начинается в свою очередь с сигнатуры 0x50 0x45 -- <<PE>>. Если данные сигнатуры не соответствуют описанным, файл не загрузится, либо не будет исполняемым.
  166.    
  167.     Далее следует сама <<DOS-заглушка>>.
  168.    
  169.     Затем начинается заголовок файла (File header, или же COFF header). Формально, file header расположен внутри PE header'а, вместе с сигнатурой и опциональным заголовком. File header представлен струтктурой на Листинге \ref{peFileHdr}.
  170.  
  171. \begin{lstlisting}[caption={Структура File header'а}, label={peFileHdr}]
  172. typedef struct _IMAGE_FILE_HEADER {
  173.   WORD      Machine;
  174.   WORD      NumberOfSections;
  175.   DWORD     TimeDateStamp;
  176.   DWORD     PointerToSymbolTable;
  177.   DWORD     NumberOfSymbols;
  178.   WORD      SizeOfOptionalHeader;
  179.   WORD      Characteristics;
  180. } IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER;
  181. \end{lstlisting}
  182.  
  183.     Здесь содержится набор полей, описывающий базовые характеристики файла, такие, как архитектура процессора (Machine), количество секций в файле (ограниченное числом 96), дата и время создания файла, указатель на таблицу символов и размер таблицы символов (NumberOfSymbols), размер опционального заголовка и характеристики файла.
  184.  
  185. %Рассмотрим только основные его поля на Листинге \ref{peOptinalHdr}.
  186. %
  187. %\begin{lstlisting}[caption={Структура Optional header'а}, label={peOptinalHdr}]
  188. %typedef struct _IMAGE_OPTIONAL_HEADER {
  189. %  ...
  190. %  DWORD        AddressOfEntryPoint;
  191. %  DWORD        BaseOfCode;
  192. %  DWORD        BaseOfData;
  193. %  DWORD        SectionAlignment;
  194. %  DWORD        FileAlignment;
  195. %  DWORD        SizeOfImage;
  196. %  DWORD        SizeOfHeaders;
  197. %  DWORD        NumberOfRvaAndSizes;
  198. %  IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES];
  199. %  ...
  200. %} IMAGE_OPTIONAL_HEADER, *PIMAGE_OPTIONAL_HEADER;
  201. %\end{lstlisting}
  202.     Далее следует опциональный заголовок (Optional header). Он содержит стандартные COFF поля, Windows-специфичные поля и директории данных. Представленные здесь поля -- RVA (Relative Virtual Address) адрес  точки входа в программу, RVA начала секции кода (BaseOfCode), RVA начала секции данных (BaseOfData), размер выравнивания секций (в байтах) при выгрузке в вирутальную память (SectionAlignment), размер выравнивания секций внутри файла (FileAlignment), размер файла, кратный SectionAlignment, размер всех заголовков, кратный FileAlignment, количество каталогов в таблице директорий, всегда равное 16 (NumberOfRvaAndSizes) и сама таблица директорий, каждый элемент которой представлен структурой на Листинге \ref{peDataDir}.
  203.    
  204. \begin{lstlisting}[caption={Структура элемента таблицы директорий, Data Directory}, label={peDataDir}]
  205. typedef struct _IMAGE_DATA_DIRECTORY {
  206.   DWORD     VirtualAddress;
  207.   DWORD     Size;
  208. } IMAGE_DATA_DIRECTORY, *PIMAGE_DATA_DIRECTORY;
  209. \end{lstlisting}
  210.  
  211.     Поле VirtualAddress Листинга \ref{peDataDir} -- RVA на таблицу, которой соответствует элемент. Второе поле -- размер. Элемент №0 , например, ответчает за таблицу экспорта, элемент №1 -- за таблицу импорта, второй -- за ресурсы (изображения, иконки, тексты) (IMAGE\_DIRECTORY\_ENTRY\_RESOURCE), №4, например, -- за безопасность (IMAGE\_DIRECTORY\_ENTRY\_SECURITY).
  212.  
  213.     Сразу за рассмотренным выше массивом идут друг за другом заголовки секций (Section headers). Для дальнейшей работы важно остановиться на данной структуре. Заголовок секции представлен на Листинге \ref{peSectionHdr}.
  214.    
  215. \begin{lstlisting}[caption={Структура заголовка секции}, label={peSectionHdr}]
  216. typedef struct _IMAGE_SECTION_HEADER {
  217.   BYTE      Name[IMAGE_SIZEOF_SHORT_NAME];
  218.  union {
  219.      DWORD  PhysicalAddress;
  220.      DWORD  VirtualSize;
  221.  } Misc;
  222.   DWORD     VirtualAddress;
  223.   DWORD     SizeOfRawData;
  224.   DWORD     PointerToRawData;
  225.   DWORD     Characteristics;
  226.  ...
  227. } IMAGE_SECTION_HEADER, *PIMAGE_SECTION_HEADER;
  228. \end{lstlisting}
  229.  
  230.     Характеристики секции представлены большим числом полей -- название, размер в виртуальной памяти (Virtual Size), размер в файле (SizeOfRawData), RVA адрес секции (VirualAddress), RAW смещение (смещение относительно начала файла) до начала секции, кратное FileAlignment, атрибуты секции (Characteristics) -- атрибуты содержимого (код, данные, неинициализированные данные), атрибуты доступа  (чтение, запись, выполнение). Как видно из описанной выше структуры, секции в PE формате имеют давольно много характеристик.
  231.    
  232.     За заголовками, как следует из Рисунка \ref{peSmall}, следует следующий большой раздел файла -- секции. При загрузке в вирутальную память их размер увеличивается до размера, кратного выравниванию. Более наглядно это представлено на Рисунке \ref{peSectionMem}. \cite{pirates}. <<Дополнительное>> пространство, образовавшееся при этом в секции -- обнуляется.
  233.    
  234. \begin{figure}[h]
  235. \caption{Выгрузка секций в память}
  236. \centering
  237. \includegraphics[width=1\textwidth]{peSectionMem}
  238. \label{peSectionMem}
  239. \end{figure}
  240.    
  241.     Исполняемый образ состоит из нескольких секций, каждая из которых требует различных прав доступа к памяти, а значит, начало секции должно быть выровнено по границе страницы. Чтобы не тратить место на диске, секции на нем не выровнены, а значит это дополнительная работа для загрузчика.
  242.  
  243.     Примерами секций могут служить таблицы импорта и экспорта. Таблица импорта (IAT, Import Address Table) соотносит вызовы функций динамических библиотек по имени или ординалу (порядковому номеру) с соответствующими адресами. Таблица экспорта (EAT -- Export Address Table) в свою очередь предоставляет адреса функций другим модулям, обращающимся к EAT за импортом. Это характерно для DLL библиотек.  Еще один пример -- таблица релокаций, используемая для вычисления адреса загрузки в случае, если предпочтительный адрес (IMAGE\_OPTIONAL\_HEADER.ImageBase) оказался недоступен. Каждая секция также представлена своей специфической структурой, которая в свою очередь представляет из себя набор структур (например, <<путь>> до имен функций в таблице импорта или экспорта).
  244.    
  245.     Представленной выше информации достаточно для общего понимания внутреннего устройства файлов PE формата.
  246.    
  247.     Процесс загрузки можно вкратце описать так:
  248.    
  249. \begin{itemize}
  250.         \item Считывание и валидация сигнатур и заголовков.
  251.         \item Выделение виртуальной памяти под приложение и попытка выгрузить его по предпочтительному адресу.
  252.         \item Вычисление адреса и размера секций в виртуальной памяти, в том числе вычисление смещений и установка атрибутов страниц согласно атрибутам секций, обнуление секций до нужной длины.
  253.         \item Анализ таблицы импорта и подгрузка соответствующих DLL, связывание импортируемых симоволов.
  254. \end{itemize}  
  255.  
  256.     На данный момент уже можно представить, что проиходит с исполняемым файлом в исходной системе. Получив базовые сведения об устройстве PE, необходимо изучить и ELF, так как он является целевым форматом.
  257.  
  258.  
  259.  
  260.  
  261.     \bigskip
  262.    
  263.     {
  264.         \subsection{Формат ELF}
  265.     }
  266.    
  267.     ELF (Executable and Linkable Format) -- формат исполняемых файлов во многих Unix-подобных системах, разработанный USL (Unix System Laboratories) в качестве переносимого для ОС на базе Intel x86. Затем, будучи доработанным компанией HP до стандарта ELF-64, распространился и для 64-разрядных систем. Стандарт ELF различает следующие типы файлов -- {\itперемещаемые файлы}, хранящие инструкции и данные для связи с объектными файлами, {\it разделяемые объектные файлы}, схожие с перемещаемыми и {\it исполняемые файлы}, содержащие необходимые данные для создания образа процесса.
  268.    
  269.     На первый взгляд схема ELF'а напоминает немного перекомпанованный PE файл. Рассмотрим ее устройство на Рисунке \ref{elfSmall}, и проверим, насколько верно это утверждение.
  270.    
  271. \begin{figure}[h]
  272. \caption{Устройство ELF}
  273. \centering
  274. \includegraphics[width=0.36\textwidth]{elfSmall}
  275. \label{elfSmall}
  276. \end{figure}   
  277.    
  278.     ELF-файл состоит из заголовка файла, таблицы программных заголовков, секций и таблицы заголовков секций в конце файла.
  279.    
  280.     Заголовок файла (ELF header) расположен в самом начале файла, как это следует из Рисунка \ref{elfSmall} и содержит общее описание структуры файла и его основные характеристики, такие, как тип, версия, архитектура, точка входа. Опустим детальное рассмотрение этой структуры.
  281.  
  282.     Таблица заголовков программы (Program header table), также известная как таблица заголовков сегментов (Segment table) идет следом за ELF header'ом. Каждый элемент этой таблицы содержит в себе тип сегмента (p\_type), расположение сегмента, точку входа, размер(p\_filesz, p\_memsz) и флаги доступа(p\_flags), согласно Листингу \ref{elfProgramHdr}. Сегменты необходимы для загрузки файла в память и исполнения. Только та часть данных, которую они охватывают нужна для работы с файлом. Остальное, с позиции загрузчика -- отладочная информация, или же метаданные.
  283.    
  284. \begin{lstlisting}[caption={Программный заголовок (заголовок сегмента)}, label={elfProgramHdr}]
  285. typedef struct _ELF64_PHDR{
  286.     Elf64_Word      p_type;  
  287.     Elf64_Word      p_flags;    
  288.     Elf64_Xword     p_filesz;
  289.     Elf64_Xword     p_memsz;
  290.    ...
  291. } Elf64_Phdr;
  292. \end{lstlisting}
  293.  
  294.     Далее следуют непосредственно секции. Секции необходимы при линковке (компоновке) файла.
  295.    
  296.     За ними вновь идет таблица -- таблица заголовков секций (Section header table). Ее структура представлена полями типа (sh\_type), смещения секции (sh\_offset), виртуальным адресом секции во время выполнения(sh\_addr) и размером (sh\_size) на Листинге \ref{elfSHdr}.
  297.    
  298. \begin{lstlisting}[caption={Программный заголовок (заголовок сегмента)}, label={elfSHdr}]
  299. typedef struct _ELF64_SHDR{
  300.     Elf64_Word      sh_name;   
  301.     Elf64_Word      sh_type;   
  302.     Elf64_Addr      sh_addr;
  303.     Elf64_Off       sh_offset;     
  304.     Elf64_Xword     sh_size;       
  305.     ...    
  306. } Elf64_Shdr;
  307. \end{lstlisting}
  308.  
  309.     Стоит заметить, что Section header может располагаться не только в конце файла, как показано на Рисунке \ref{elfSmall}, но и, например, между секций. Его положение задано стандартом, как <<плавающее>>. \cite{elf}
  310.    
  311.     %ссылка на стандарт
  312.  
  313.     На этом, формально, описание заголовков можно закончить. Процесс выгрузки ELF файла в память во многом схож с таковым для PE файлов. Следующим пунктом этого раздела будет краткое сравнение форматов.
  314.  
  315.  
  316.  
  317.     \bigskip
  318.    
  319.     {
  320.         \subsection{Сравение форматов}
  321.     }
  322.  
  323.     На основании сказанного выше, можно отметить следующее:
  324.    
  325. \begin{itemize}
  326.         \item PE формат представлен гораздо бОльшим числом структур и всевозможных подструктур.
  327.         \item Поля PE формата предоставляют загрузчику исчерпывающую информацию для выгрузки в память, делая код позиционно-зависимым.
  328.         \item Размещение структур в PE файле задано более жестко.
  329.         \item В PE имеется лишняя неиспользуемая <<заглушка времен DOS-овского прошлого>> системы.
  330.         \item ELF использует полностью позиционно-независимый код и глобальную таблицу смещений, которая жертвует временем выполнения в пользу расходования памяти.
  331.         \item В случае отсутствия необходимости в перебазировании адресов, PE-файлы имеют преимущество очень эффективного кода, но при наличии перебазирования издержки в использовании памяти могут быть значительными.
  332. \end{itemize}  
  333.  
  334.     Исходя из всего этого, можно предположить, что работа с ELF файлом проще, чем с PE. Однако опровергнуть или доказать это утверждение удасться только при непосредственной работе по устройству архитектуры. На данный момент имеется достаточно информации об устройстве исходного и целевого форматов. Можно приступить к изучению самого компилятора.
  335.  
  336.  
  337.     \bigskip
  338.    
  339.     {
  340.         \section{ОБЗОР КОМПИЛЯТОРА BeRo TinyPascal}
  341.     }
  342.  
  343.     Рассматриваемым в данной работе компилятором является компилятор языка Pascal, {\it Bero TinyPascal}. Он был разработан в 2006 году, тогда двадцатилетним немецким программистом-музыкантом Бенджамином <<BeRo>> Россо (Benjamin Rosseaux) и на данный момент распространяется под лицензией zlib (совместимой с GNU GPU) из его репозитория на GitHub (github.com/BeRo1985/berotinypascal).
  344.    
  345.     Компилятор является самоприменимым и преобразует исходный код (из подмножества языка Pascal) в 32-битный ассемблерный код платформы Windows x86.
  346.    
  347.     Условно его можно разделить на 2 части -- <<верхнюю>>, btpc.dpr, сам компилятор BTPC реализующий фазы анализа и синтеза, и <<нижнюю>>, rtl.asm, библиотеку RTL (RunTime Library), частично реализующую фазы синтеза.
  348.  
  349.  
  350.  
  351.     \bigskip
  352.  
  353.     {
  354.         \subsection{Библиотека рантайма, RTL}
  355.     }
  356.    
  357.     Библиотека RTL  частично релизует фазу синтеза, а именно -- распределение памяти и запись выходного ассемблерного кода в выходной поток (файл). Непосредственно генерация кода на целевом языке происходит на <<верхнем>> уровне, в BTPC.
  358.  
  359.     Библиотека состоит из 9 встроенных функций:
  360.    
  361. \begin{enumerate}
  362.         \item RTLHalt — остановка программы.
  363.         \item RTLWriteChar — запись char’а на stdout.
  364.         \item RTLWriteInteger — запись целого на stdout, принимает два параметра: число и ширину вывода.
  365.         \item RTLWriteLn — выводит на stdout символ новой строки.
  366.         \item RTLReadChar — считывает символ из stdin, результат кладёт в \verb|EAX|.
  367.         \item RTLReadInteger — считывает целое из stdin, результат кладёт в \verb|EAX|.
  368.         \item RTLReadLn — пропускает стандартный ввод до конца файла или ближайшего перевода строки.
  369.         \item RTLEOF — возвращает в \verb|EAX| число больше 1, если достигнут конец файла (следующий символ прочитать невозможно) или 0 в противном случае.
  370.         \item RTLEOLN — устанавливает в \verb|DL| 1, если следующий символ \textbackslash n, 0 — в противном случае.
  371. \end{enumerate}
  372.  
  373.     Также имеется импорт утилитарных функций из библиотеки kernel32.dll таких, как HeapAlloc для работы с кучей, выделяющая 4 Мбайта памяти при инициализации, устанавливающая на них указатель стека и функция, HeapFree, в конце работы программы освобождающая эту память и функции обработки ввода данных -- GetStdHandle, SetConsole, ReadConsoleInputA.
  374.  
  375.     Все взаимодействие с библиотекой осущестляется посредством таблицы встроенных функций (RTLFunctionTable). В таблице, в описанном выше порядке находятся указатели на соответствующие функции, при этом таблица в течение работы всегда доступна в регистре \verb|ESI|. Особенностью работы рантайма является неизменяемость этого регистра.
  376.    
  377.     Примечательной особенностью, сбивающей поначалу с толку является взаимодействие RTL и BTPC. В этих файлах нет ни одной ссылки друг на друга, а в RTL после перехода на метку \verb|StubEntryPoint| и подготовки самой библиотеки, на последней строке присутствует метка \verb|ProgramEntryPoint|, указывающая по сути в никуда. То есть стандартным поведением RTL, как самостоятельного процесса будет ошибка сегментирования (Segmentation fault), см Листинг \ref{originEntry} (оригинальная нотация соблюдена).
  378.  
  379. \begin{lstlisting}[caption={Метки StubEntryPoint и ProgramEntryPoint, получающие управление}, label={originEntry}]
  380. StubEntryPoint:
  381.  INVOKE GetStdHandle,BYTE -10
  382.  MOV DWORD PTR StdHandleInput,EAX
  383.  INVOKE SetConsoleMode,EAX,1+2
  384.  INVOKE HeapAlloc,EAX,HEAP_GENERATE_EXCEPTIONS+HEAP_ZERO_MEMORY
  385.               +HEAP_CREATE_ALIGN_16,4194332
  386.  ...
  387. .LIBRARY "kernel32.dll"
  388. IMPORT WriteFile "WriteFile"
  389. IMPORT HeapFree "HeapFree"
  390. ProgramEntryPoint:
  391. \end{lstlisting}
  392.    
  393.     Это первая встретившаяся <<особенность>> реализации. Идея BeRo будет понятна при рассмотрении самого BTPC.
  394.  
  395.  
  396.  
  397.     \bigskip
  398.    
  399.     {
  400.         \subsection{Компилятор BTPC}
  401.     }
  402.    
  403.     Компилятор BTPC (BeRo TinyPascal Comiler), представленный исходным кодом btpc.dpr и  является <<верхней>> и главной частью системы. В нем происходит как {\it фаза анализа} -- чтение входного потока, лексический анализ, синтаксический анализ, генерация промежуточного представления, так и {\it фаза синтеза} -- генерация кода на целевом языке. Оптимизация, как стадия компиляции отсутствует впринципе.
  404.    
  405.     Код, как в промежуточном представлении, так и целевой,
  406. генерируется по входному потоку <<as is>>, как есть, то есть без каких-либо оптимизаций и изменений. Входным потоком на первом этапе служит поданный на stdin код. Входным потоком на втором этапе служит сгенерированный на первом этапе промежуточный код. Он представляет из себя обычный массив (\verb|Code|), каждый $i$-й элемент которого является идентификатором операции (которых 45), а $(i+1)$-й --- данными, связанными с операцией (\verb|Value|).
  407.    
  408.     После порождения промежуточного кода запускается процедура \verb|AssembleAndLink|, в которой с обходом массива промежуточного кода генерируется ассемблерный код в виде отдельных кодов инструкций в hex формате. Это также просходит в 2 этапа:
  409.    
  410.     На первом этапе библиотека RTL из пункта выше вручную компилируется в исполняемый файл rtl.exe. Для этого, вероятно, используется Borland Turbo Assembler со специальной конфигурацией, настроенной на получение минималистичного выходного файла. Этот файл преобразуется специальной программой, написанной BeRo также на Pascal (rtl2pas.dpr) в pascal-строки вида \verb|OutputCodeString(#77#90 ... #$90#$90)|, где после символов \verb|#| идут десятичные представления байтов поданной на вход программы, а дополнение до длины в 255 элементов происходит путем записи недостающего количества байтов \verb|$90|, являющихся кодами (opcode) ассемблерной инструкции \verb|NOP|, в конец строки. В примере выше, элементы \verb|#77#90| при переводе обратно в hex представление становятся байтами \verb|4D 5A|, или <<MZ>>, и являются сигнатурой PE файла, описанной ранее в данной работе. Очевидно, что файл размером в 1000 байт будет записан 4 подобными строками, последняя из которых дополнена до длины 255 инструкциями \verb|NOP| (No operation). Размер файла в строковом представлении при этом будет искуственно увеличен на 20 байт (20 инструкций \verb|NOP|). Полученные таким образом строки записываются в <<итоговую>> последовательность кода (массив \verb|OutputCodeData|).
  411.    
  412.     На данном этапе внутри BTPC имеется полноценный работоспособный (инициализирующий библиотеку и намеренно <<сваливающийся>> в Seg fault) файл, записанный в массив.
  413.    
  414. \begin{lstlisting}[caption={Генерация инструкции байтами кода операции}, label={originMovEax}]
  415. procedure OCMovEAXDWordPtrESP;
  416. begin
  417.  EmitByte($8b); EmitByte($04); EmitByte($24);
  418.  LastOutputCodeValue:=locMovEAXDWordPtrESP;
  419. end;
  420. \end{lstlisting}   
  421.    
  422.     Далее процедурами \verb|EmitChar(char)|, \verb|EmitByte(integer)|, \verb|EmitInt16(integer)|,  \verb|EmitInt32(integer)| и более частными их случаями (например, процедура на Листинге \ref{originMovEax}, отвечающая за инструкцию \verb|MOV EAX,DWORD PTR [ESP]|) в массив поверх инструкций \verb|NOP| записываются порожденные из промежуточного кода ассемблерные инструкции, также в виде кодов операций, но уже с префиксом \verb|$| -- в hex формате.
  423.    
  424.     Однако, не все инструкции получили свои процедуры и бОльшая часть кода генерируется прямо в \verb|AssembleAndLink| блоками \verb|switch|-оператора, пободными представленному на Листинге \ref{originSwitch} блоку, эквивалентному инструкциям на Листинге \ref{originSwitchAsm}. Таким образом, на месте <<падения>> из метки \verb|ProgramEntryPoint| появляется новый, <<скомпилированный>> код, являющийся программой, поданной на вход компилятору.
  425.    
  426. \begin{lstlisting}[caption={Генерация инструкций (opcode) из промежуточной инструкции OPStl}, label={originSwitch}]
  427. OPStL:begin
  428.  OCPopEAX;
  429.  Value:=Value-4;
  430.  if Value=0 then begin
  431.   EmitByte($89); EmitByte($04); EmitByte($24);
  432.  end else if (Value>=-128) and (Value<=127) then begin
  433.   EmitByte($89); EmitByte($44); EmitByte($24); EmitByte(Value);
  434.  end else begin
  435.   EmitByte($89); EmitByte($84); EmitByte($24); EmitInt32(Value);
  436.  end;
  437.  LastOutputCodeValue:=locNone;
  438.  PC:=PC+1;
  439. end;
  440. \end{lstlisting}   
  441.  
  442. \begin{lstlisting}[caption={Ассемблерные инструкции блока OPStl}, label={originSwitchAsm}]
  443. POP EAX
  444. MOV DWORD PTR [ESP],EAX
  445. MOV DWORD PTR [ESP+BYTE Value],EAX
  446. MOV EAX,DWORD PTR [ESP+DWORD Value]
  447. \end{lstlisting}   
  448.  
  449.     Pascal, который обрабатывает BTPC, является подмножеством обычного языка Pascal, в нем запрещены дженерики, шаблоны, перегрузка операторов и прочие <<новые>> возможности, которых не было в Delphi 7 и в самом BTPC на момент создания (2006 год), но при этом присутствуют и <<незадекларированные>> возможности, связанные с недоработкой логики компилятора (об этом позднее).
  450.    
  451.     В самом конце процедуры \verb|AssembleAndLink| находится еще одна архитектурная особенность BTPC -- патчевание выходного файла. Фрагмент этой части представлен на листинге \ref{originPatch}.
  452.    
  453. \begin{lstlisting}[caption={Патчевание выходного файла}, label={originPatch}]
  454. { Size Of Code }
  455. PEEXECodeSize:=OutputCodeGetInt32($29)+(OutputCodeDataSize-CodeStart);
  456. OutputCodePutInt32($29,PEEXECodeSize);
  457. { Get section alignment }
  458. PEEXESectionAlignment:=OutputCodeGetInt32($45);
  459. ...
  460. { Calculate and patch image size }
  461. OutputCodePutInt32($5d,PEEXESectionVirtualSize+OutputCodeGetInt32($39));
  462. { Patch section raw size }
  463. OutputCodePutInt32($115,OutputCodeGetInt32($115)+(OutputCodeDataSize-CodeStart));
  464. \end{lstlisting}
  466.      На Литинге \ref{originDump} представлен дамп памяти, соответствующий началу файла BTPC в PE32 формате. Как и упомяналось ранее, выходной файл скомипилированной RTL библиотеки очень мнималистичен. В частности на месте DOS-<<заглушки>> находится авторская сигнатура, хотя сигнатуры, необходимые PE-загрузчику тоже присутствуют (<<MZ>>, <<PE>>).
  467.    
  468. \begin{lstlisting}[caption={Дамп BTPC}, label={originDump}]
  469. 0000-0010:  4d 5a 52 c3-42 65 52 6f-5e 66 72 00-50 45 00 00  MZR.BeRo ^fr.PE..
  470. 0000-0020:  4c 01 01 00-00 00 00 00-00 00 00 00-00 00 00 00  L....... ........
  471. 0000-0030:  e0 00 0f 03-0b 01 00 00-3f cf 00 00-00 00 00 00  ........ ?....... 
  472. 0000-0040:  00 00 00 00-c4 10 00 00-00 10 00 00-0c 00 00 00  ........ ........
  473. 0000-0050:  00 00 40 00-00 10 00 00-00 02 00 00-04 00 00 00  ..@..... ........
  474. \end{lstlisting}
  476.     Исследованного ранее устройства формата PE32 и комментариев BeRo достаточно для понимания патчевания. Происходит следующее:
  478. \begin{itemize}
  479.         \item Корректировка ближних переходов (\verb|JMP xx, CALL xx|) --- это связано с особенностью генерации меток и переходов по ним при кодогенерации.
  480.         \item Корректировка размера кода (рассмотренное ранее поле SizeOfCode Optional header'а).
  481.         \item Получение имеющегося выравнивания и патчевание с помощью него вирутальных размеров секций (SectionHeader.VirtualSize). Это необходимо при загрузке файла на исполнение, см Рисунок \ref{peSectionMem}.
  482.         \item Корректировка \verb|ImageSize|'а, размера образа.
  483.         \item Патчевание RAW размера секции (размер в файле).
  484. \end{itemize}
  486.     Почти ко всем полям добавляется размер инжектированного кода входной программы.
  488.     Компилятор работает, а значит, патчевание происходит успешно и нескольких подкорректированных полей достаточно, чтобы PE загрузчик обработал файл корректно.
  489.    
  490.     Однако, становится заметна еще одна неприятная особенность кода --- наличие <<магических>> констант, не к каждой из которых имеется соответсвующий поясняющий комментарий. Оптимальность порожденного кода также остает желать лучшего, хотя данная проблема находится вне контекста работы.
  491.    
  492.     На этом изучения входных данных и теоретической подготовки достаточно для перехода к портированию.
  494.    
  495.    
  496.    
  497.     \bigskip
  499.     {
  500.         \section{ПОРТИРОВАНИЕ}
  501.     }
  502.    
  503.     Первым делом необходимо разобраться с внутренним устройством библиотеки RTL и портировать ее. Затем изменить кодогенерацию на порождение инструкций набора x64. Далее -- пропатчевать выходной ELF аналогичным описанному ранее способом и убедиться в работоспособности полученного ELF файла.
  507.     \bigskip
  508.    
  509.     {
  510.         \subsection{Библиотека RTL}
  511.     }
  512.    
  513.     Верхнеуровневое описание библиотеки приводилось ранее. Теперь необходимо портировать ее на платформу amd64. Для этого нужно заменить системные вызовы к WinAPI на аналоги в Linux'е. Исходные системные вызовы BeRo реализовал с помощью макросов своей среды разработки.
  514.    
  515.      На платформе же amd64 систеные вызовы осуществляются подготовкой аргументов вызываемой функции с помощью регистров и затем вызовом инструкции \verb|syscall|. Более детально распределение регистров на архитектурах i386 и x86\_64 представлено в Таблице \ref{syscall}.
  516.    
  517.     Так как BeRo работал с макросами, использующими стэк для обращения к WinAPI, а системные вызовы \verb|syscall| используют регистры, необходимо постараться обеспечить аналогичную <<чистоту>> функций RTL, чтобы конечный резльтат функционировал так же, как и оригинал.
  518.    
  519.     Портируем простую функцию -- RTLWriteChar. Назначние понятно из названия. На Листинге \ref{originWriteChar} представлена оригинальная функция, а на листинге \ref{myWriteChar} -- ее портированная версия.
  520.    
  521. \begin{table}
  522.     \caption {Интерфейс 32 и 64-битных системных вызовов}
  523.    \label {syscall}
  524.    \begin{tabular}{|c|c|c|c|c|c|c|c|c|c|}
  525.    \hline
  526.    архитектура & инструкция & syscall \# & ret value & arg1 & arg2 & arg3 & arg4 & arg5 & arg6 \\ \hline
  527.    i386        & int \$0x80 & eax        & eax       & ebx  & ecx  & edx  & esi  & edi  & ebp  \\ \hline
  528.    x86\_64     & syscall    & rax        & rax       & rdi  & rsi  & rdx  & r10  & r8   & r9   \\ \hline
  529.    \end{tabular}
  530. \end{table}
  531.    
  532.     Вызовом \verb|syscall| обратимся к фунции \verb|Write()|. Ее подбробную спецификацию можно получить командой <<\verb|man 2 write|>> в терминале. Распределим ее аргументы по соответствующим регистрам.
  533.    
  534. \begin{lstlisting}[caption={Оригинал RTLWriteChar}, label={originWriteChar}]
  535. RTLWriteCharBytesWritten: DB 0x90, 0x8D, 0x40, 0x00
  536. RTLWriteChar:
  537.  push esi
  538.  lea esi, [esp+8]
  539.  pushad
  540.  invoke WriteFile, dword ptr StdHandleOutput,  esi, byte 1,
  541.             offset RTLWriteCharBytesWritten, byte 0
  542.  popad
  543.  pop esi
  544.  ret 4
  545. \end{lstlisting}       
  546.    
  547.     С портированием даже такой простой функции выявляется еще одна <<особенность>> --- данные внутри кода. На Листинге \ref{originWriteChar} количество байт, отправленное на stdout, хранится по метке \verb|RTLWriteCharBytesWritten|, которая расположена не в секции данных, а в секции кода, в связи с чем секция кода является единственной (!) секцией в файле и отмечена как {\it исполняемая, перезаписываемая}.
  548.    
  549.     Это может привести к непредвиденным последствиям в работе, начиная от Seg fault'а и заканчивания внедрением стороннего кода. Если не учесть всех деталей (что спустя 10 лет может быть давольно затруднительно даже для автора), можно столкнуться с большими трудностями, особенно с учетом не просто портирования, но и увеличнения разрядности инструкций.
  550.    
  551.     Обезопасить себя можно, отрефакторив код параллельно с портированием. Для инициализированных данных в новой версии введена секция \verb|.data|, дле неинициализированных -- секция \verb|.bss|.
  552.    
  553.     В связи с введением дополнительных регистров в x64 и меньшей надобности сохранять регистры в стеке при вызовах, из набора существующих инструкций исчезли аналоги инструкций \verb|pusha, pushad| и \verb|popa, popad| для 64-битных регистров. Но, поскольку так или иначе, при \verb|syscall|'ах регистры меняются, стоит самостоятельно ввести аналогичные инструкции в виде макросов -- \verb|pushall'| и \verb|popall|, запушивающих регистры от \verb|rdi| до \verb|rax| и возвращающих их из стека в обратном порядке. Эти и другие отладочные инструкции добавлены в секцию \verb|.bss|.
  554.    
  555.      Для отладочных целей и для соблюдения best practices введем также и создание стекового фрейма. \cite{zubkov}. Стоит заметить, что в портированной версии используется более привычный для Unix-подобных систем AT\&T синтаксис ассемблерных иснтрукций (см. Листинг \ref{myWriteChar}).
  556.    
  557. \begin{lstlisting}[caption={Портированная версия RTLWriteChar}, label={myWriteChar}]
  558. .section .data
  559. RTLWriteIntegerBuffer: .byte 0x3c, 0x57, 0x72, 0x69, 0x74, 0x69, ...
  560.    
  561. .section .text
  562. RTLWriteChar:
  563.     pushall
  564.     movq    %rsp,   %rbp
  565.    
  566.     movq    $1,     %rax    #syscall #1 = Write();
  567.     movq    $1,     %rdi    #param1 = write_to = 1 = stdout
  568.     movq    %rbp,   %rsi    #p2 = write_from = %rbp = stack
  569.     addq    $72,    %rsi    #reach arg on top of stack
  570.     movq    $1,     %rdx    #p3 = count = single_byte
  571.     syscall
  572.    
  573.     popall
  574.     ret     $8
  575. \end{lstlisting}   
  576.  
  577.     Портируем следующую функцию, RTLWriteInteger. Ее листинг может быть опущен. Стоит лишь заметить, что эта функция используется для вывода целых чисел на stdout и она обращается к RTLWriteChar. Отдельно скомпилируем и соберем с помощью ld имеющийся рантайм:
  578.    
  579. \centerline{\texttt{gcc -c rtl64.s}}
  580. \centerline{\texttt{ld rtl64.o -g -o rtl64}}
  581.  
  582.     Протестируем так все имеющиеся функции. На этом этапе появлилась еще одна типичная для работы с legacy кодом проблема --функция RTLReadInteger оказалась нерабочей потому, что прочитанное значение сохранялось в \texttt{EAX}, а затем просто затиралось при восстановлении регистров из стека. Судя по состоянию репозитория и отсутсвию коммитов, исправляющих баг, функция оставалась нерабочей на протяжении 10(!) лет. После уведомления об этом автора, функция спустя какое-то время была исправлена (значение регистра в стеке теперь обновляется), однако это еще раз поднимает вопрос эффективности работы с legacy кодом.
  583.    
  584.     Портированная функция была также исправлена.
  585.  
  586.     На данном этапе новые функции работают корректно и ведут себя предсказуемо. Портируем аналогично все остальные функции рантайма.
  587.    
  588.     Теперь, когда имеется полный набор RTL функций, необходимо подготовить окружение -- зарезервировать стек так, как это делает BeRo. Чтобы инициализировать достаточный для работы программы стек можно пройти по нему, записывая какие-либо значения через некоторые промежутки, пока не встретится Guard Page --  см Рисунок \ref{guard}.
  589.    
  590. \begin{figure}[h]
  591. \caption{Резервирование стека}
  592. \centering
  593. \includegraphics[width=0.36\textwidth]{guard}
  594. \label{guard}
  595. \end{figure}
  596.    
  597.     При более детальном изучении проблемы выяснилось, что для каждого запущенного процесса Linux держит список регионов вирутальной памяти и в случае ошибки при обращении к странице, проверяет, не произошел ли Seg fault. Если не произошел, значит было обращение к неинициализированной странице, а значит необходимо лишь выделить еще одну страницу виртуальной памяти и добавить к региону. Столкнуться с Guard Page можно при  этом только при использовании некоторых функций дебаггинга, содержащих \texttt{malloc}. Значит, нет необходимости в аналогичных действиях в новой библиотеке.
  598.    
  599.     Осталось лишь скомпилировать библиотеку в <<заглушку>> для вставки ее в BTPC. Так как программа для перевода написана на Delphi Pascal'е, необходимо найти все необходимые инструменты для ее запуска, что в 2017 году -- не сама простая задача. Так как цель пободной программы предельно ясна, было принято решение переписать эту программу на более удобном для парсинга файлов языке -- C++. С помощью новой программы rtl64topas переводим скомпилированную библиотеку в строковый формат и вставляем ее на место заглушки  BTPC -- в функцию \texttt{EmitStubCode}.
  600.    
  601.     На этом можно считать, что библиотека RTL портирована и на новой платформе имеется набор функций, аналогичных оригинальной RTL.
  602.    
  603.    
  604.    
  605.    
  606.     \bigskip
  607.    
  608.     {
  609.         \subsection{Генерация кода}
  610.     }
  611.    
  612.     Следующим этапом является изменение генерации кода, порождаемого на целевой платформе. Необходим набор инструкций x64.
  613.    
  614.     Переведем инсутркуцию <<\verb|MOV R10, (R12 + R13)|>> (в AT\&T-синтаксисе соответственно: \verb|mov (%r12, %r13), %r10|) вручную. Для этого понадобятся справочные материалы курса <<Низкоуровневое программирование>>. \cite{makarov}.
  615.    
  616.    
  617.     %ссылка на x64b макарова
  618.    
  619. \begin{figure}[h!]
  620. \caption{Вычисление кода операции вручную}
  621. \centering
  622. \includegraphics[width=0.95\textwidth]{modrm2}
  623. \label{modrm2}
  624. \end{figure}
  625.    
  626. \begin{enumerate}
  627.     \item Переводим номера операндов в двоичный вид. Регистр-приемник -- \texttt{R10} подходит под формат <<R?>>.
  628.         \item Находим инструкцию \texttt{MOV} в таблице кодов инструкций i8086+. Нужен формат <<r\slash m \textrightarrow R?>>. Итого, КОП инструкции = 0x8B.
  629.         \item \texttt{R10} в двоичном представлении имеет длину 4 бита, а значит не входит в отведенные 3 бита Rn байта ModR/M.
  630.         \item Для представления подобных <<больших>> регистров понадобится байт <<Префикс REX>>.
  631.         \item Старший бит \texttt{R10} уходит в бит R префикса REX и расширяет Rn в байте ModR/M.
  632.         \item  Согласно таблице ModR/M для 32-разрядных инструкций, биты R/M байта ModR/M = 100, а биты Mod = 00. Это дает дополнительный байт SIB.
  633.     \item Старший бит регистра \texttt{R12}, равный 1, взводит бит X в префиксе REX и расширяет номер индекса в SIB.
  634.         \item Байт SIB выглядит, как \verb|[#Base + #Index*|$2^{Scale}$\verb|]|. Базу образует регистр \texttt{R12}. 3 младших его бита = 100 и устанавливаются на место 3х битов Base в SIB.
  635.         \item Индекс(Index) в SIB составляют 3 младших бита регистра \texttt{R13} = 101.
  636.         \item Так как в инструкции простое сложение (1 регистр + 1 регистр), биты Scale в байте SIB = 00 и дают $2^{Scale} = 2^0 = 1$.
  637.         \item Старший бит регистра \texttt{R13} уходит в бит B префикса REX. Это расширяет набор базового регистра в байте SIB.
  638.         \item Сконкатенируем байт префикса REX: <<0100>> + <<W:1>> + <<R:1>> + <<X:1>> + <<B:1>> = 01001111, что в hex записи дает 0x4F. Префикс REX найден.
  639.         \item Сконкатенируем байт ModR/M: <<Mod:00>> + <<Rn:010>> + <<R/M:100>> = 00010100, что дает байт 0x14.
  640.         \item Сконкатенируем наконец байт SIB: <<Scale:00>> + <<Index:101>> + <<Base:100>> = 00101100, что дает байт 0x2C.
  641. \end{enumerate}
  642.    
  643.     Путем конкатенации полученных байтов имеем инструкцию  <<\verb|MOV R10, (R12 + R13)|>> в виде 0x4F 0x8B 0x14 0x2C. На Рисунке \ref{modrm2} описанный выше процесс представлен более наглядно.
  644.    
  645.     Подобных инструкций, требующих перевода в BTPC около 70, без повторений. Очевидно, что этот способ совсем не оптимален и очень затратен. Один упущенный бит меняет инстукцию или создает несуществующую. В связи с этим и после того, как процесс перевода стал понятен, можем воспользоваться более быстрым путем --- выписать необходимые инструкции в формате x64, скомпилировать файл а затем дизассемблировать его. На выходе получим все, что необходимо, чтобы заменить генерируемые байты в процедурах, пободных Листингам \ref{originMovEax} и \ref{originSwitch}.
  646.    
  647.     После этого кодогенерацию можно также считать портированной, так как теперь инструкции порождаются в новом, 64-битном формате.
  648.    
  649.    
  650.    
  651.     \bigskip
  652.    
  653.     {
  654.         \subsection{Формирование ELF файла}
  655.     }
  656.    
  657.     Теперь, когда имеется портированная библиотека в функции \texttt{EmitStubCode}, а новый код генерируется в формате x64, остается лишь пропатчевать ELF файл, собранный в заглушке, подобно патчеванию PE файла у BeRo.
  658.    
  659.     При компиляции и обычной линковке командами
  660.    
  661. \centerline{\texttt{gcc -c rtl64.s}}
  662. \centerline{\texttt{ld rtl64.o -g -o rtl64}}
  663.  
  664.     в файл может попасть множество <<мусора>> -- функции библиотек, таблицы символов, лишние секции и прочие метаданные, в которых нет надобности при загрузке и выполнении файла. Мусором в данном случае считается все, чего нет в <<образцовом>> и очень минималистичном исходном PE файле. На Листинге \ref{elfSections} представлены секции полученного обычной линковкой файла, и найденные утилитой readelf командой <<\verb|readelf -S rtl64|>>.
  665.    
  666.     Особенностью ELF формата является наличие пустой секции. Она всегда имеет нулевой номер. Далее идет секция кода \texttt{.text}, затем данных \texttt{.data}. После чего следуют отладочные секции -- секция с именами секций \texttt{.shstrtab} (Section header string table), секция с таблицей символов \texttt{.symtab} и наконец секция строк- меток в ассемблерном коде \texttt{.strtab}.
  667.    
  668.     Сразу вырисовывается следующая проблема -- секция кода, к которой должен был конкатенироваться код находится в самом начале файла, так что дописывание кода после метки \texttt{ProgramEntryPoint} в RTL сделает файл неработоспособным. В эталонном файле присутствует лишь одна секция. Постараемся добиться максимально приближения к этому, но с учетом введенных при рефакторинге дополнительных секций (данных инициализированных и неинициализированных). То есть, необходимо оставить лишь 2 секции (кода и данных), при этом приблизив секцию кода к концу файла.
  669.    
  670. \begin{lstlisting}[caption={Секции файла rtl64}, label={elfSections}]
  671.  [#]  Name              Type             Address           Offset
  672.       Size              Size.Ent         Flags    Link Info  Align
  673.  [ 0]                   NULL             0000000000000000  00000000
  674.       0000000000000000  0000000000000000           0     0     0
  675.  [ 1] .text             PROGBITS         00000000004000b0  000000b0
  676.       0000000000000339  0000000000000000  AX       0     0     1
  677.  [ 2] .data             PROGBITS         00000000006003e9  000003e9
  678.       0000000000000067  0000000000000000  WA       0     0     1
  679.  [ 3] .shstrtab         STRTAB           0000000000000000  00000450
  680.       0000000000000027  0000000000000000           0     0     1
  681.  [ 4] .symtab           SYMTAB           0000000000000000  000005f8
  682.       0000000000000420  0000000000000018           5    40     8
  683.  [ 5] .strtab           STRTAB           0000000000000000  00000a18
  684.       000000000000024e  0000000000000000           0     0     1
  685. \end{lstlisting}
  686.  
  687.     Лишние секции никак не заданы в исходном коде RTL64, а значит попадают в файл на стадии линковки. Это заметно по размеру файла после этих действий. Зададим линкеру не генерировать мусор в виде функций библиотеки stdlib и секций с таблицами:
  688.    
  689. \centerline{\texttt{ld rtl64.o -g -o rtl64 -nostdlib -s}}
  690.  
  691.     При повторном чтении ELF'а оказывается, что секция \texttt{shstrtab} осталась и все так же хранит имена других секций. Нулвая секция тоже на месте, но это не существенно.
  692.    
  693.     В комплекте binutils есть утилита для редактирования в том числе и исполнимых файлов. С помощью этой утилиты, strip, <<вырезаем>> оставшуюся секцию \texttt{shstrtab}:
  694.    
  695. \centerline{\texttt{strip -R shstrtab rtl64}}
  696.  
  697.     Однако, вновь прочитав файл на предмет секций обнаруживаем там \texttt{shstrtab}. Так как секция хранит имена других секций, она всегда генерируется при линковке и всегда в конце файла. Однако, для выполнения, согласно спецификации, она не нужна. Так что можно будет очистить ее при генерации кода. Остается проблема с тем, что секция кода все еще внутри файла и прикрыта секцией данных.
  698.  
  699.     Для того, чтобы поменять местами секции необходимо использовать специальный линкер-скрипт для ld. Это файл, представляющий какие данные куда отобразятся при линковке файла, в том числе здесь задается и порядок вхождения секций. Выполним линковку согласно скрипту на Листинге \ref{linker}, заменив им стандартный скрипт (может быть получен командой <<\verb|ld --verbose|>>). Для этого запустим линкер с еще одной опцией:
  700.    
  701. \centerline{\texttt{ld rtl64.o -g -o rtl64 -T linkerScript.ld -nostdlib -s}}
  702.  
  703. В представленном скрипте указана точка входа --\texttt{\_start}, адреса размещения секций данных и кода, и выделяемая память на стэке и в куче.
  704.    
  705. \begin{lstlisting}[caption={Скрипт линкера ld}, label={linker}]
  706. stack_size = 4194332;
  707. heap_size = 256;
  708. ENTRY(_start)
  709. SECTIONS
  710. {
  711.     . = 0x4000b0;
  712.     .data : { *(.data) }
  713.     .bss :  { *(.bss)  *(COMMON) }  
  714.     . = 0x6000d3;
  715.     .text : { *(.text) }
  716. }
  717. \end{lstlisting}
  718.  
  719.     После линковки по этому скрипту, секции кода и данных поменялись местами. Секция \texttt{shstrtab} все также замыкает файл. Но из-за минималистичности скрипта, линкер перестал делать какие-либо оптимизации и вычисления, полностью положившись на файл, в котором ничего кроме порядка секций не задано. После некоторых манипуляций приводим текущий скрипт к виду стандартного скрипта (verbose), но с описанными в Листинге \ref{linker} изменениями. Получаем оптимизированный скомпанованный файл. Обновляем заглушку \texttt{EmitStubCode} в BTPC.
  720.    
  721.     Пробуем собрать компилятор, отключив генерацию кода. На данном этапе компилятор лишь выводит заглушку. Выводит успешно. Файл, наполненый \texttt{NOP}'ами для выравнивания под размер в 255 может быть запущен и также предсказуемо и намеренно сваливается в Seg fault.
  722.    
  723.     Однако, при тестировании есть проблема -- файл собран слишком минималистично и в нем отсутствует какая-либо полезная при отладке информация. Несмотря на то, что код RTL64 был тщательно изучен, отлаживать и тестировать ассемблерный код без таблицы символов и без единственной именованной метки очень затруднительно. В связи с этим было приянто решение вернуть на место секции \texttt{symtab} и \texttt{strtab}, убрав соответствующие опции линкера.
  724.    
  725.     На данный момент RTL64 может быть протестирован и отлажен, так как внутри устроен абсолютно корректно. Это одно из преимуществ новой библиотеки перед оригиналом, где отстстуют какие-либо метки, а многие команды распознаются неправильно из-за наличия байтов данных в коде, которые дизассемблером путаются с реальными командами.
  726.    
  727.     Теперь необходимо отправить на выполнение весь сгенерированный код, содержащий логику компилируемой программы. Для этого необходимо пропатчевать поля файла согласно внесенным изменениям.
  728.    
  729.     Поскольку секция кода, хоть и была перенесена в конец, все равно осталась скрытой отладочными секциями, необходимо <<разрезать>> файл надвое, вставить туда код и <<склеить>> обратно. На данный момент представление файла полностью соответствует изображенному на Рисунке \ref{elf}.
  730.    
  731. \begin{figure}[h!]
  732. \caption{Устройство конечного ELF файла}
  733. \centering
  734. \includegraphics[width=0.8\textwidth]{elf}
  735. \label{elf}
  736. \end{figure}
  737.  
  738.     Кав видно из Рисунка \ref{elf}, файл выстроен в соответсвии описанными ранее требованиями и допусками: секция текста идет после секции данных, за ней следуют отладочные секции, среди которых имеется и таблица заголовков секций. На  этой схеме также показаны поля ELF, рассматривавшиеся в самом начале работы, а именно -- поля программных заголовков (в данном случае Data program header) и поля заголовков секций, такие, как {\it имя} (sh\_name), содержащее смещение внутри секции \texttt{shstrtab} по которому лежит название этой секции, {\it смещение} (sh\_offset), указывающее на начало секции кода в файле и {\it размер секции} (sh\_size).
  739.    
  740.     Код компилируемой программы будет порождаться в секции кода поверх операций \texttt{NOP}, положение которых отмечено серым цветом.
  741.    
  742.     Итого, чтобы добиться работоспособности подобного файла, необходимо пропатчевать как минимум поля, указанные в Таблице \ref{patch}.
  743.    
  744. \begin{table}
  745.    \caption {Редактируемые поля}
  746.        \label {patch}
  747.    \begin{tabular}{|c|c|c|c|}
  748.    \hline
  749.    ~                       & Смещение до поля                           & Размер & Значение   \\ \hline
  750.    Elf\_hdr.e\_shoff       & 0x28                                          & 8      & += injSize \\ \hline
  751.    Text\_phdr.p\_filesz    & s(Elf\_hdr)+s(p\_hdr)+0x20                 & 4      & += injSize \\ \hline
  752.    Text\_phdr.p\_memsz     & s(Elf\_hdr)+s(p\_hdr)+0x28                 & 4      & += injSize \\ \hline
  753.    Text\_shdr.sh\_size     & Elf\_hdr.e\_shoff+injSize+2*s(s\_hdr)+0x20 & 8      & += injSize \\ \hline
  754.    Shstrtab\_shdr.sh\_offs & Elf\_hdr.e\_shoff+injSize+3*s(s\_hdr)+0x18 & 8      & += injSize \\ \hline
  755.    Symtab\_shdr.sh\_offs   & Elf\_hdr.e\_shoff+injSize+4*s(s\_hdr)+0x18 & 8      & += injSize \\ \hline
  756.    Strtab\_shdr.sh\_offs   & Elf\_hdr.e\_shoff+injSize+5*s(s\_hdr)+0x18 & 8      & += injSize \\ \hline
  757.    \end{tabular}
  758. \end{table}
  759.  
  760.     Значения всех представленных полей должны быть увеличены на размер сгенерированного кода (injSize). В Таблице \ref{patch}, в столбце <<Смещение до поля>> функция s(x) обзначает размер соответствующей структуры, и далее прибавлено смещение конкретного поля внутри структуры. Elf\_hdr.e\_shoff вместе с тем -- значение этого поля после патчевания этого поля в первой строке таблицы. Поля указаны в том порядке, в котором они должны быть отредактированы, так как есть зависимость значений некоторых полей от другого поля.
  761.  
  762.     Все смещения и значения могут быть с легкостью вычислену вручную, однако это не самый эффективный подход, так высока вероятность ошибки в таком случае. С целью вычисления полей была доработана программа rtl64topas.cpp. Она не только разбивает файл на 2 набора строк (начало файла до секции кода включительно и конец файла), но и также вычисляет смещения и значения полей, после чего с помощью функций \verb|OutputCodePutInt32(offset, value)| значения записываются в итоговый набор опкодов инструкций.
  763.    
  764. \begin{lstlisting}[caption={Редактирование полей ELF файла}, label={elfPatch}]
  765. const EndStubSize=$8f7;
  766.      ElfHdrShoff_val0=$488;
  767.      TextPhdrFilesz_val0=$349;
  768.      OffsElfHdrShoff=$28;
  769.      OffsTextPHdrFilesz=$98;
  770.  ...
  771.  InjSize:=OutputCodeDataSize-EndStubSize-PECodeStart;
  772. {ElfHdr.e_shoff, 8b}
  773.  OutputCodePutInt32(OffsElfHdrShoff + $1,  ElfHdrShoff_val0 + InjSize);
  774.  OutputCodePutInt32(OffsElfHdrShoff + $1 + $4, 0);
  775. {TextPhdr.p_filesz, 4b}
  776.  OutputCodePutInt32(OffsTextPHdrFilesz + $1, TextPhdrFilesz_val0 + InjSize);
  777. \end{lstlisting}
  778.  
  779.     Так как быйты представлены в формате Little Endian (по страшему адресу -- старшие  байты) и с допущением, что генерируемый промежуточный код имеет 32-х разрядный формат, а значит не может превзойти или добраться по размеру до x64 кода, старшие 4 байта (расположенные по старшему адресу) 8-байтных полей могут быть обнулены. Пример такого редактирования поля -- в Листинге \ref{elfPatch}. Везде добавляется один байт из-за устройства процедуры \texttt{OutputCodePutInt32}, которая редактирует байт по текущему адресу, а не со следующего байта.
  780.  
  781.     Еще одной доработкой BTPC является двукратное увеличение значения \texttt{Value} (данных для операции, представленной предыдущим значнием) там, где Value является {\it смещением}. Например, в операциях \verb|subq Value, %rsp| (формально, Value в подобной инструкции не является смещением, однако вычитание у BeRo реализовано прибавлением отрицательного значения, а сами инструкции вычитания используются для аллокации переменных в стеке, в связи с чем значение должно быть увеличено в 2 раза) или же \verb|movq Value(%rsp), %rax|.
  782.    
  783.     На этом основную часть портирования можно считать завершенной.
  784.    
  785.     Данный проект в его текщем состоянии доступен из репоизтория на Github \\(github.com/avbelyaev/course-compilers).
  786.    
  787.    
  788.    
  789.    
  790.     \bigskip
  791.    
  792.     {
  793.         \section{ТЕСТИРОВАНИЕ И ОТЛАДКА}
  794.     }
  795.    
  796.     Далее следует отладка в стиле TDD разработки (Test Driven Development), т.е. необходимо получить эталонное поведение, сравнивая поведение оригинала и новой релаизации на тестах. В случае <<падения>> необходимо дизассемблировать и изучить причину подробнее.
  797.  
  798.     Далее следует простой пример одной итерации такого TDD подхода к отладке. На Рисунке \ref{diff}, в левом столбце содержится код, сгенерированный новым компилятором по программе из Листинга \ref{pascal}, в правом столбце -- код, порожденный исходным компилятором.
  799.  
  800. \begin{lstlisting}[caption={Тестирование работы функции, обращающейся к 2м функциям RTL}, label={pascal}]
  801. program RTLFucnTest;
  802. var x:integer;
  803.    
  804. procedure simpleProc(s:integer);
  805. begin
  806.  Write('tst');
  807.  WriteLn(s+3);
  808. end;
  809.  
  810. begin
  811.  x:=5;
  812.  simpleProc(x);
  813. end.
  814. \end{lstlisting}
  815.  
  816.     Как видно из результата сравнения дизассемблирования, ассемблерная функция (метка) порождается на том же месте, что и процедура в верхнеуровневом коде. Далее пушится значение аргумента и следует переход на метку функции. Можно также заметить, что печать строки это на самом деле печать одного символа $n=strlen$ раз (функцией RTLWriteChar по смещению 0x8), а вся арифметика происходит прямо в стеке. Далее следуют еще 2 RTL функции -- RTLWriteInteger и RTLWriteLn по смещениям 0x10 и 0x18 соответственно. Заканчивается программа переходом на функцию RTLHalt.
  817.  
  818. \begin{figure}[h!]
  819. \caption{Сравнение порожденных частей}
  820. \centering
  821. \includegraphics[width=0.95\textwidth]{diff}
  822. \label{diff}
  823. \end{figure}
  824.  
  825.     В данном случае имеется проблема с аллокацией места в стеке под переменные -- инструкция \verb|sub #0x4, %rsp| сдвигает стек на 4 байта, что приводит к коллизии с остальными 8-байтовыми значениями в нем. Если теперь изменить функцию, порождающую эту инструкцию, то оба файла отработают корректно. Первый -- под Linux x64, второй -- под Windows 32.
  826.  
  827.     Если же проблема на уровне заглушки и требует пересборки библиотеки, то необходимо ортедактировать код, скомпилировать и слинковать его, затем преобразовать в набор строк, вставить выходной результат программы rtl64topas на соответствующее место в BTPC. Затем вновь идут итерации тестирования.
  828.    
  829.  
  830.     Таким образом мы получаем полностью работоспособный компилятор, который порождает ELF файлы для использования под Linux. Следующим этапом является раскрутка компилятора. Необходимо подать на вход компилятору под Windows исходный код компилятора под Linux. На выходе получится компилятор, работающий под Windows, но генерирующий x64 инструкции под Linux. После подачи ему на вход себя же, полуим полностью работоспособный компилятор Pascal, работающий под Linux.
  831.    
  832.     В случае неудачи, необходимо возврщаться к итеративному подходу для локлизации ошибки и ее исправления. После чего вновь вернуться к раскрутке. Это может быть давольно долгим и трудоемким процессом. Отдельно стоит отметить препятствующие этому факторы.
  833.    
  834.    
  835.  
  836.    
  837.     {
  838.         \subsection{Особенности исходной реализации}
  839.     }
  840.  
  841.     Чтобы избежать ошибок, которые значительно замедляли данную работу, стоит отметить имеющиеся проблемы, которые появлялись по мере работы над портированием:
  842.    
  843. \begin{itemize}
  844.         \item В RTL нет ни одного комментария на несколько сотен строк ассемблерного кода притом, что в некоторых функциях используются не самые очевидные решения.
  845.         \item В RTL данные хранятся внутри кода, в нарушение практик по безопасному программированию, что еще и приводит к невозможности отладить работу (можно рассматривать это, как своеобразный прием антиотладки -- техники злоумышленников по скрытию реальных действий программы), дизассемблировав файл, так как данные принимаются за инструкции.
  846.         \item Отсутствуют фреймы функций, что делает невозможным отладку в некоторых средах.
  847.         \item Содержимое регистров, которое можно принять за <<мусор>> после некоторых операций, спустя некоторое количество инструкций будет переиспользовано и дальнейший код ожидает увидеть там определенное значение. В других местах мусор перезаписывается.
  848.         \item Наличие ошибок в коде, одна из которых просущестововала 10 лет.
  849.         \item В BTPC присутствует несколько десятков комментариев (многие из которых дублируют названия функций, в которых эти комментраии указаны) на почти 3000 строк кода собственного множества Pascal'а. Какая-либо иная документаия отсутствует.
  850.         \item Для формирования <<заглушки>> используется устревшее ПО, найти которое становится все сложнее.
  851.         \item Обилие никак не аннотированных <<магических констант>> в коде, как часть <<worst practice>>.       
  852. \end{itemize}  
  853.    
  854.     Описанные выше проблемы действительно способны вызвать значительные затруднения в работе с legacy кодом даже для автора кода спустя большое количество времени, так что в новом проекте была предпринята попытка избавиться хотя бы от части проблем.
  855.        
  856.    
  857.     \clearpage
  858.    
  859.     {
  860.         \section{ЗАКЛЮЧЕНИЕ}
  861.     }
  862.    
  863.     В результате данной работы была произведена попытка портирования программы, написанной более 10 лет назад, которая {\it отчасти} увенчалась успехом. В ходе работы было изучено внутренне представление файлов разных форматов для разных операционных систем, был изучен процесс компиляции и сборки выходного файла, а также был установлен контроль над всем данным процессом, что привело к положительному результату и ожидаемым последствиям. Былы изучена генерация опокдов из инструкций, а затем и упаковка опкодов, а также разные подходы к компоновке выходных файлов.
  864.    
  865.     Во время работы было встречено и преодолено множество проблем, характерных для работ подобного рода.
  866.    
  867.     Данная работы может быть названа выполненной лишь отчасти, так как вероятно в коде еще множество ошибок и однажды кто-нибудь с ними столкнется, после чего придется вновь углубляться в изучение неочевидного кода, так как большая часть кода нового компилятора (вся фаза анализа) досталась ему по наследству от старого.
  868.  
  869.  
  870.   \newpage
  871.  
  872.         \begin{thebibliography}{00} % 00 влияет на выравнивание номеров записей в списке литературы.
  873. \bibitem{tour} Peering Inside the PE: A Tour of the Win32 Portable Executable File Format [Электронный ресурс] \newblock --- Режим доступа: https://msdn.microsoft.com/en-us/library/ms809762.aspx
  874. \bibitem{elf} Executable and Linkable Format (ELF) Specification [Электронный ресурс] \newblock --- Режим доступа: http://www.skyfree.org/linux/references/ELF\_Format.pdf
  875. \bibitem{makarov} А. Макаров, Р. Насыров. Написание собственной операционной системы, ``x64b'', учебное пособие \newblock --- Издательство: самоиздат., 2011
  876. \bibitem{zubkov}С. Зубков, Assembler для DOS, Windows и Unix \newblock ---МСК:  ДМК Пресс, 2015. \newblock --- 206 с.
  877. \bibitem{pirates} PE (Portable Executable): На странных берегах [Электронный ресурс] \newblock --- Режим доступа: https://habrahabr.ru/post/266831/
  878.  
  879. \end{thebibliography}
  880.    
  881.     %\addcontentsline{toc}{section}{Список литературы}
  882.  
  883.    
  884.     \end{document}
Advertisement
Add Comment
Please, Sign In to add comment
Public Pastes
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy.  OK, I Understand
Not a member of Pastebin yet?
Sign Up, it unlocks many cool features!