гос / sp-lect (1)
.pdfБудь яка версія інсталятора встановлює пакет асемблера, побудований на основі Microsoft (R) Macro Assembler (x86) зі складу пакету Windows Driver Kits (C:\MASM) та інтегроване середовище розробки програм RadAsm IDE (C:\RadAsm) з інтегрованим налагоджувачем OllyDbg (C:\RadAsm\Debug\ OllyDbg). Наявність встановленого Microsoft Visual C++ 2008 SP1 Redistributable Package, який вимагає Microsoft (R) Macro Assembler
перевіряється і, за необхідності, він також встановлюється.
Відмінності інсталяторів полягають у різних наборах додаткових утиліт
(C:\RadAsm\Tools), довідкових файлів (C:\RadAsm\Help і C:\MASM\HELP) і
додаткового програмного забезпечення. Ніяких додаткових налаштувань встановлене програмне забезпечення не потребує і відразу готове до використання.
2.2 Склад асемблерів Microsoft Macro Assembler
Асемблери являють собою набір (пакет) програм і допоміжних файлів, які дозволяють отримувати різноманітні програмні модулі для певної процесорної архітектури і середовища (підсистеми виконання) певної операційної системи.
Засоби асемблера також дозволяють розробляти програми, які працюють без операційних систем, наприклад, BIOS, яка починає працювати ще до завантаження операційної системи. Власне і сама операційна система також може бути розроблена за допомогою асемблера.
Основу будь якого асемблера складають транслятор і компанувальник. Транслятор – програма для перетворення вихідного тексту (коду)
програми в об’єктний файл (код), що містить машинні коди команд мікропроцесора. Під терміном «асемблер» в багатьох випадках розуміють саме транслятор, а ту систему позначень, яка використовується для запису вихідного тексту (коду) програми називають мовою асемблера.
Компанувальник (редактор зв’язків, лінкер) – програма для перетворення об’єктного файлу (коду) в програмний модуль, який може виконуватися в середовищі певної підсистеми виконання операційної системи.
Після встановлення пакету MASM його файли розташовуються в підкаталогах BIN, HELP, INC, LIB і TOOLS каталогу встановлення асемблера. Власне засоби розробки розташовуються в підкаталозі BIN і серед них варто зазначити транслятори ml.exe та/або ml64.exe, компанувальник link.exe і компілятор ресурсів (див. далі) rc.exe.
Всі вище перераховані та інші програмні засоби, розташовані в каталозі BIN, традиційно являють собою консольні додатки з інтерфейсом командного рядка, що не завжди виявляється зручним. Роботу з консольними додатками в зручному графічному інтерфейсі забезпечує інтегроване середовище розробки
(англ. Integrated Development Environment, IDE) RadAsm.
2.3 Склад і взаємозв’язок файлів проекту
При розробці програмного забезпечення використовують термін проект, під яким зокрема розуміють набір пов’язаних поміж собою текстових і бінарних файлів. Мінімальний проект програми на асемблері може складатися з єдиного файлу з вихідним текстом програми. Традиційно цей файл має розширення «asm».
До складу проекту також можуть входити файли з розширеннями «inc» і «mac», що підключаються до вихідного тексту за допомогою спеціальних директив. Розширення цих файлів, узагалі кажучи, не має особливого значення, але традиційно mac-файли містять так звані макровизначення, а inc-файли – це так звані заголовні файли, що містять опис типів, прототипів, структур, констант, тощо.
При розробці програм з використанням елементів графічного інтерфейсу ОС Windows до складу проекту, як правило, також входять так звані файли ресурсів. Файли ресурсів являють собою текстові файли з розширенням «rc», що містять спеціальні директиви опису використовуваних програмою елементів графічного інтерфейсу, зрозумілі компілятору ресурсів. Мову опису ресурсів знати корисно, однак на практиці для розробки файлів ресурсів широко
використовуються програмні засоби підтримки так званого візуального програмування – редактори ресурсів.
Файли ресурсів можуть посилатися на бінарні (двійкові) файли іконок, курсорів, шрифтів, і т.і. За допомогою компілятора ресурсів файли ресурсів і бінарні файли на які вони посилаються, перетворюються у бінарні файли з розширенням «res», які в подальшому використовується компанувальником при складанні проекту і потрапляють до складу програмного модуля.
У деяких випадках (як правило, під час створення програмних модулів відмінних від звичайних «ехе»-файлів) для складання проекту компанувальник потребує ще деякої додаткової інформації, яка міститься у так званому файлі визначення програмного модуля. Цей текстовий файл з розширенням «def» містить зрозумілі компанувальнику спеціальні директиви, які керують його роботою. Ім’я def-файлу передається компанувальнику за допомогою спеціальних параметрів командного рядка.
2.4 Етапи розробки проекту
Розробка проекту починається із створення всіх вихідних файлів проекту, які, зазвичай, розміщують в одному каталозі. Створення і редагування текстових файлів можна виконувати у будь-якому текстовому редакторі, але при цьому слід пам’ятати що транслятор взагалі не підтримує текст у Unicode, а коректне відображення в створюваній програмі тексту із символів кирилиці можливе лише за умови використання редактора, який використовує «рідне» кодування підсистеми виконання програм ОС.
Рисунок 2.1 демонструє у вигляді граф-схеми етапи розроблення проекту, які позначено цифрами над дугами граф-схеми. Після створення проекту та редагування всіх потрібних вихідних файлів, зазвичай, спочатку виконують компіляцію файлів ресурсів за допомогою компілятору ресурсів rc.exe.
Компіляція файлів ресурсів може бути виконано і після трансляції модулів з вихідним текстом програми, але на етапі налагодження програми, файли ресурсів доводиться, як правило, редагувати щонайменше, і, отримавши
відразу бінарний файл з ресурсами, його потім багаторазово використовують під час повторного компонування програми у разі змін у тексті вихідних файлів.
Рисунок 2.1 Файли ресурсів можуть містити синтаксичні помилки, для виправлення
яких можливо знадобиться багаторазове повернення до редагування цих файлів із повторною компіляцією.
Після компіляції ресурсних файлів переходять до трансляції вихідних текстів модулів та/або програми. Для програм, що не використовують rc-файли, зразу ж виконується трансляція вихідних текстів модулів та/або програми.
Якщо вихідні тексти програми і модулів не мають помилок, то трансляція закінчуються створенням об’єктних модулів – файлів з розширенням «obj». Проект може складатися з декількох asm-файлів і, відповідно, з декількох отриманих після їх трансляції об’єктних модулів. Асемблери припускають складання програмного файлу з різних отриманих раніше об’єктних файлів, що можуть використовуватися у різних проектах уже не на рівні вихідного тексту, а у вигляді готових obj-бібліотек або lib-модулів.
Якщо всі бінарні та об’єктні файли отримано, то виконується складання проекту з цих файлів за допомогою компанувальника. Отримання obj-файлів є умовою необхідною, але в деяких випадках недостатньою для того, щоб отримати програмний модуль. У вихідному тексті зустрічаються директиви, які не важливі для транслятора, але мають значення для компанувальника і у разі його повідомлення про неможливість з певних причин створити програмний модуль, доводиться повертатися назад до редагування вихідного тексту і повторної трансляції.
Важко сподіватися на те, що більш-менш серйозна програма зразу запрацює правильно. Отже, етап налагодження майже завжди неминучий і до того ж найдовший. Для підвищення ефективності процесу налагодження програм транслятор та компанувальник мають спеціальні засоби. Організація їх взаємодії з налагоджувачем виконується за допомогою відповідних опцій командного рядка.
Транслятор долучає до об’єктного файлу «зайву» інформацію, а компонувальник на її підставі формує вже інформацію для налагоджувача, залучаючи її вже до програмного файлу та/або створюючи спеціальні файли з налагоджувальними даними. Це збільшує розмір програмного файлу, і коли процес налагодження закінчено (нарешті!) і потреба в інформації налагоджування відпадає, то фінальний варіант програмного файлу потрібно отримувати у «чистому» вигляді, змінивши відповідні параметри командного рядка транслятора та компанувальника. Слід зауважити, що наявність налагоджувальної інформації спрощує процес його дизасемблювання сторонніми особами.
У результаті роботи програми компанування бінарна інформація для налагоджувача і текстова для розробника може створюватися і у вигляді окремих файлів (*.map, *.pdb). Створення цих файлів також потрібно замовляти відповідними параметрами командного рядка під час виклику компанувальника.
Після отримання програмного модуля виконується запуск програми під керуванням налагоджувача. Можна, але не варто переходити безпосередньо до пробного запуску програми. Пробний запуск програми може допомогти виявити і певним чином визначити місця виникнення помилок, але для їх локалізації все одно доведеться користуватися послугами налагоджувача, і до того ж зовнішні прояви помилок можуть з’являтися далеко від місця їх фактичного виникнення.
Виправлення помилок супроводжується редагуванням вихідних текстових файлів, і, звичайно, повторною трансляцією і компануванням. Після виправлення всіх явних помилок знову виконується пробний запуск програми і починається процес комплексного тестування.
2.5 Структура вихідного тексту програми для асемблеру MASM
Вихідний текст програми на асемблері складається з директив, команд, макрокоманд і коментарів. В записах директив, команд і макрокоманд також можуть використовуватися оператори асемблера. Традиційно більшість асемблерів підтримують запис єдиної директиви, команди або макрокоманди в одному рядку вихідного тексту програми.
Ознакою коментаря є символ «;» (крапка с комою), зустрівши який у будь-якому місці вихідного тексту, транслятор припиняє його обробку до кінця рядка з цим символом. Така поведінка транслятора обумовлює те, що коментарі розміщують або з початку нового рядка, або справа від директив, команд і макрокоманд на одному з ними рядку.
Для багаторядкових коментарів зручно використовувати директиву
comment обмежувач
Будь який текст, що складається з багатьох рядків
обмежувач
У якості обмежувача можна використовувати будь-яке слово з припустимих символів алфавіту асемблера, за умови що це слово не
зустрічається в тексті самого коментаря, а один і той самий обмежувач можна використовувати багаторазово в різних директивах comment.
А чи не за багато ми тут приділяємо уваги коментуванню програми? Гарна звичка коментувати вихідний текст своїх програм з лихвою компенсує витрачений на це час на етапі її супроводу, допоможе підвищити її якість і безпечність за рахунок подальшої ревізії коду (англ. Code review або Code inspection).
2.5.1 Вихідний текст 32-розрядного додатку ОС Windows NT
Вихідний текст 32-розрядного додатку ОС Windows NT для Microsoft Macro Assembler (ml.exe) має наступний вигляд:
.386 | .486 | .586 | .686 | .386p | .486p | .586p | .686p
; Директиви визначення набору команд FPU, ; розширення MMX
; і розширення XMM
; Директива визначає модель пам’яті ; та конвенцію виклику ; Це додаткові параметри трансляції
[<директиви визначення даних і резервування пам’яті>]
.code
[<визначення підпрограм>] <точка входу>:
[<код>]
ret
[<визначення підпрограм>] end <точка входу>
В квадратні дужки [] взято не обов’язкові елементи, а символом «|» позначено операцію «виключне або».
Директива .386 | .486 | .586 | .686 | .386p | .486p | .586p | .686p
повідомляє асемблеру, набір команд якого мікропроцесора буде використовуватися в програмі, наприклад, .386 відповідає мікропроцесорам сумісним із системою команд Intel 80386.
Директива .386 є необхідною і достатньою, а якщо програма потребує використання команд, специфічних для більш пізніх моделей мікропроцесорів, то потрібно явно зазначити .486|.586|.686. Якщо цього не зробити, то асемблер «не впізнає» ці команди і трансляція завершиться з помилкою «error
A2085:instruction or register not accepted in current CPU mode».
Директива визначення набору команд із пост суфіксом «р», тобто
.386р|.486р|.586р|.686р повідомляє асемблеру, що в програмі також будуть використовуватися привілейовані команди для даної моделі мікропроцесору. Використання набору привілейованих команд має сенс лише при розробці драйверів режиму ядра, а для звичайних додатків режиму користувача вони все одно не доступні.
За необхідності також потрібно зазначити ще й набір команд розширень MMX (.mmx або .k3d для AMD) і XMM (.xmm), а для використання команд арифметичних операцій з плаваючою комою потрібно ще й вказати .387.
Використання директив визначення набору команд забезпечує апаратну сумісність розробленої програми із визначеною моделлю мікропроцесора не
дозволяючи використовувати відсутні і ній команди та/або регістри у вихідному тексті програми.
Директива .model flat [, c | stdcall] визначає модель пам’яті, що використовується програмою та конвенцію виклику – правила організації зв’язку програми з іншими модулями, які можуть бути створені з використанням інших мов. Усі програми для Windows використовують єдину так звану без сегментну або пласку модель пам’яті FLAT, а конвенції виклику ми детально будемо розглядати у розділі «Модульне програмування».
Директиви option дозволяють зазначити додаткові параметри трансляції вихідного тексту програми. Частина з них є еквівалентами опцій командного рядка транслятора.
Директиви include [<шлях>\]ім’я.inc використовується для підключення до вихідного тексту програми, взагалі кажучи, будь яких текстових файлів, синтаксис яких зрозумілий транслятору. Як правило, це файли з розширеннями «mac», що містять так звані макровизначення, і файли з розширеннями «inc», що містять опис типів, прототипів, структур, констант тощо. Окрім власних файлів з макровизначеннями і заголовних файлів проект може використовувати також стандартні заголовні файли та файли з макровизначеннями MASM, які розташовуються у підкаталозі INC каталогу встановлення асемблеру.
Зустрівши в програмі директиву include, транслятор відкриває заданий з її допомогою файл і починає його оброблення від початку до кінця так, немов би це продовження вихідного тексту програми, а лише потім переходить до обробки наступного рядка вихідного тексту.
У технологічному лістингу програми, який є робочим варіантом вихідного тексту програми для транслятора, замість кожної директиви include насправді вставляється текст того файлу, на який йде посилання. Якщо у свою чергу, ці файли містять власні директиви include, то їх оброблення виконується так само. Лише отримавши такий повний текст, складений з різних файлів, асемблер переходить до його трансляції.
Мати повний лістинг програми корисно. Його створення потрібно замовляти параметром командного рядка транслятора /Fl і крім того асемблер має спеціальні засоби керування лістингом програми. Аналіз лістингу дозволяє детальніше розібратися у структурі програми та виявити помилки, пов’язані з макровизначеннями. На етапі оброблення рядків з include асемблер контролює вміст inc-файлів і виводить попереджувальні повідомлення, або навіть може зовсім припинити оброблення у разі виявлення помилки.
Аналіз причини помилки можна провести на підставі тексту файлу лістингу. Спочатку треба перевірити правильність завдання місцеположення inc– файлів на диску. Параметр <шлях> директиви include хоча і позначений квадратними дужками як необов’язковий, але якщо його не задати у вихідному тексті програми, це все одно доведеться зробити, але вже у командному рядку транслятора за допомогою параметра /I<шлях> (стандартні inc-файли містяться у підкаталозі INC каталогу встановлення MASM). Перевірки шляхів доступу також потрібно виконати у «продовженнях» inc-файлів, що містять власні директиви include.
Директиви includelib [<шлях>\]ім’я.lib задають перелік усіх файлів бібліотек імпорту і статичних бібліотек, які знадобляться компонувальнику при збиранні програмного модуля. Методи зв’язування із зовнішніми бібліотеками ми детально будемо розглядати пізніше у розділі «Модульне програмування», а тут лише зауважимо, що параметр <шлях> хоча є необов’язковим, але якщо його не зазначити у тексті програми, то це все одно доведеться зробити за допомогою відповідного параметра командного рядка лінкеру /LIBPATH:<шлях>, і що всі стандартні бібліотеки MASM знаходяться у підкаталогах x86 (для 32-розрядних додатків) і x64 (для 64-розрядних додатків) підкаталогу LIB каталогу встановлення асемблера.
Директиви .stack, .const, .data, .data?, .code це директиви керування секціями програми. Код програми являє собою зв'язний список машинних команд, тобто команди програми йдуть одна за іншою в строго певному порядку, що задається алгоритмом. Тому цілком природно, що зберігати цей