Функции компоновщика. Руководство новичка по эксплуатации компоновщика

Теги: Линкер, компоновщик, объектный файл, статическая библиотека, динамическая библиотека, исполнение программы, определение, объявление

Гид по линкерам для начинающих. Часть 1

Перевод статьи Beginner"s guide to linkers с примерами и дополнениями.

Следующие понятия используются как синонимы: линкер и компоновщик, определение и дефиниция, объявление и декларирование. Серым выделены вставки с примерами.

Именование составных частей: что внутри Си файла

Во-первых, необходимо понять разницу между объявление и определением. Определение связывает имя с реализацией этого имени, которая может быть как данными, так и кодом:

  • Определение переменной приводит к тому, что компилятор выделяет под неё память и возможно заполняет каким-то начальным значением
  • Определение функции приводит к тому, что компилятор генерирует код для этой функции

Объявление говорит компилятору Си, что где-то в программе, возможно, что и в другом файле, есть определение, связанное с этим именем (замечу, что определение сразу может быть и объявлением, для которого определение находится на том же месте).

Для переменных, определение бывает двух типов

  • Глобальные переменные, которые существуют всё время существования программы (статическое размещение) и к которым обычно обращаются из многих функций
  • Локальные переменные, которые существуют только во время выполнения функции, в которой они объявлены (локальное размещение) и доступные только внутри неё

Для ясности, «доступный» значит, что на переменную можно ссылаться по имени, которое связано с её определением.

Есть пара случаев, когда всё не так очевидно

  • Статические локальные переменные на самом деле глобальные, потому что существуют всё время жизни программы, хотя и доступны внутри одной функции
  • Как и статические переменные, глобальные переменные, доступные только внутри одного файла, где они объявлены, тоже глобальные

Стоит сразу напомнить о том, что объявление функции статической уменьшает её область видимости до того файла, в котором она определена (именно, к ней могут обратиться функции из этого файла).

Локальных и глобальных переменные также можно разделить на неинициализированные и инициализированные (которые предварительно заполнены каким-то значением).

В конце концов, мы можем работать с переменными, созданными динамически с помощью функции malloc (или оператора new в С++). К области памяти по имени обратиться нельзя, поэтому мы используем указатели – именованные переменные, которые хранят адрес неименованного участка памяти. Этот участок может быть также освобождён с помощью free (или delete), поэтому считают, что память имеет динамическое размещение.

Соберём теперь всё вместе

Code Data
Global Local Dynamic
Initialized Uninitialized Initialized Uninitialized
Declaration int fn(int x); extern int x; extern int x; N/A N/A N/A
Definition int fn(int x) { ... } int x = 1;
(at file scope) 		int x;
(at file scope) 		int x = 1;
(at function scope) 		int x;
(at function scope) 		(int* p = malloc(sizeof(int));)

Проще посмотреть на эту программу

/* Это определение неинициализированной глобальной переменной */ int x_global_uninit; /* Это определение инициализированной глобальной переменной */ int x_global_init = 1; /* Это определение неинициализированной глобальной переменной, но к ней можно обратиться по имени только из этого же си файла */ static int y_global_uninit; /* Это определение инициализированной глобальной переменной, но к ней можно обратиться по имени только из этого же си файла */ static int y_global_init = 2; /* Это объявление глобальной переменной, которая существует где-то в другом месте программы */ extern int z_global; /* Это объявление функции, которая определена где-то в другом месте программы. Можно добавть служебное слово extern. Но это не имеет значения */ int fn_a(int x, int y); /* Это определение функции, но так как она определена со словом static, то доступна только в этом же си файле */ static int fn_b(int x) { return x+1; } /* Это определение функции. Её параметтры рассматриваются как локальные переменные */ int fn_c(int x_local) { /* Это определение неинициализированной локальной переменной */ int y_local_uninit; /* Это определение инициализированной локальной переменной */ int y_local_init = 3; /* Этот код ссылает на локальные и глобальные переменные и функции по имени */ x_global_uninit = fn_a(x_local, x_global_init); y_local_uninit = fn_a(x_local, y_local_init); y_local_uninit += fn_b(z_global); return (y_global_uninit + y_local_uninit); }

Пусть этот файл называется file.c. Собираем так

Cc -g -O -c file.c

Получим объектный файл file.o

Что делает компилятор Си

Работа компилятора си в том, чтобы превратить файл с кодом из понимаемого (иногда) человеком в нечто, понимаемое компьютером. На выходе компилятор даёт объектный файл, который на платформе UNIX имеет обычно расширение.o, а на windows .obj. Содержимое объектного файла это, по сути, два типа объектов

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

Экземпляры этих объектов будут иметь имена, связанные с ними – имена переменных или функций, определения которых привели к их генерации.

Объектный код – это последовательность (подходяще закодированных) машинных инструкций, соответствующих инструкциям на языке Си – всем этим if, while и даже goto. Все эти команды оперируют разного рода информацией, и эта информация должны быть где-то сохранена (для этого нужны переменные). Кроме того, они могут обращаться к другим кускам кода, который определён в файле.

Каждый раз, когда код обращается к функции или переменной, компилятор позволяет это делать только если он видел объявление этой переменной или функции. Объявление это обещание компилятору, что где-то в программе существует определение.

Работа компоновщика (линкера) в исполнении этих обещаний, но что делать компилятору, когда он сталкивается с неопределёнными сущностями?

По сути, компилятор просто оставляет заглушку. Заглушка (ссылка) имеет имя, но значения, связанного с ним, ещё не известно.

Теперь мы можем примерно описать, как будет выглядеть наша программа

Анализ объектного файла

Пока мы работали с абстрактной программой; теперь важно посмотреть,как она выглядит на практике. На платформе UNIX можно воспользоваться утилитой nm. На Windows примерным аналогом служит dumpbin с флагом /symbols, хотя есть и порт GNU binutils, который включает nm.exe.

Посмотрим, что нам выдаст для написанной выше программы nm:

00000000 b .bss 00000000 d .data 00000000 N .debug_abbrev 00000000 N .debug_aranges 00000000 N .debug_info 00000000 N .debug_line 00000000 N .debug_loc 00000000 i .drectve 00000000 r .eh_frame 00000000 r .rdata$zzz 00000000 t .text U _fn_a 00000000 T _fn_c 00000000 D _x_global_init 00000004 C _x_global_uninit U _z_global

Для ранее скомпилированного файла file.o

Nm file.o

От системы к системе вывод может отличаться, но ключевая информация – это класс каждого символа и его размер (если доступен). Класс может иметь следующие значения

  • Класс U означает неизвестный (unknown), или заглушку, как было сказано выше. Всего два таких объекта: fn_a и z_global (некоторые версии nm могут также вывести section, которая в данном случае будет *UND* или UNDEF)
  • Класс t или T обозначает, что код определён – t локально или T – это статическая функция. Также может быть выведена секция.text
  • Класс d и D обозначают инициализированную глобальную переменную, d – локальную, D – не локальную. Сегмент для данных переменных обычно.data
  • Для неинициализированных глобальных переменных используется класс b, если статическая/локальная или B и C, если нет. Обычно это сегмент.bss или *COM*

Есть и другие гнусные классы, представляющие какие-то внутренние механизмы компилятора.

Что делает компоновщик. Часть 1

Как мы уже определились ранее, объявление переменной или функции – это обещание компилятору, что где-то есть определение этой переменной или функции, и что работа линкера заключается в том, чтобы исполнять эти обещания. На нашей диаграммой объектного файла это также может быть названо «заполнением пустот».

Для иллюстрации этого вот вам ещё один си файл в дополнение к первому

/* Инициализированная глобальная переменная */ int z_global = 11; /* Вторая глобальная переменная с именем y_global_init, но обе они статические */ static int y_global_init = 2; /* Объявление ещё одной глобальной переменной */ extern int x_global_init; int fn_a(int x, int y) { return(x+y); } int main(int argc, char *argv) { const char *message = "Hello, world"; return fn_a(11,12); }

Пусть этот файл называется main.c. Компилируем его как и ранее

Cc –g –O –c main.c

С этими двумя диаграммами теперь мы видим, что все точки могут быть соединены (а если нет, то компоновщик выдаст ошибку). У каждой вещи своё место, и у каждого места есть вещь, и компоновщик может заменить все заглушки, как показано на рисунке.


Для ранее скомпилированных main.o и file.o сборка исполняемого файла

Cc -o out.exe main.o file.o

Вывод nm для исполняемого файла (в нашем случае out.exe):

Symbols from sample1.exe: Name Value Class Type Size Line Section _Jv_RegisterClasses | | w | NOTYPE| | |*UND* __gmon_start__ | | w | NOTYPE| | |*UND* __libc_start_main@@GLIBC_2.0| | U | FUNC|000001ad| |*UND* _init |08048254| T | FUNC| | |.init _start |080482c0| T | FUNC| | |.text __do_global_dtors_aux|080482f0| t | FUNC| | |.text frame_dummy |08048320| t | FUNC| | |.text fn_b |08048348| t | FUNC|00000009| |.text fn_c |08048351| T | FUNC|00000055| |.text fn_a |080483a8| T | FUNC|0000000b| |.text main |080483b3| T | FUNC|0000002c| |.text __libc_csu_fini |080483e0| T | FUNC|00000005| |.text __libc_csu_init |080483f0| T | FUNC|00000055| |.text __do_global_ctors_aux|08048450| t | FUNC| | |.text _fini |08048478| T | FUNC| | |.fini _fp_hw |08048494| R | OBJECT|00000004| |.rodata _IO_stdin_used |08048498| R | OBJECT|00000004| |.rodata __FRAME_END__ |080484ac| r | OBJECT| | |.eh_frame __CTOR_LIST__ |080494b0| d | OBJECT| | |.ctors __init_array_end |080494b0| d | NOTYPE| | |.ctors __init_array_start |080494b0| d | NOTYPE| | |.ctors __CTOR_END__ |080494b4| d | OBJECT| | |.ctors __DTOR_LIST__ |080494b8| d | OBJECT| | |.dtors __DTOR_END__ |080494bc| d | OBJECT| | |.dtors __JCR_END__ |080494c0| d | OBJECT| | |.jcr __JCR_LIST__ |080494c0| d | OBJECT| | |.jcr _DYNAMIC |080494c4| d | OBJECT| | |.dynamic _GLOBAL_OFFSET_TABLE_|08049598| d | OBJECT| | |.got.plt __data_start |080495ac| D | NOTYPE| | |.data data_start |080495ac| W | NOTYPE| | |.data __dso_handle |080495b0| D | OBJECT| | |.data p.5826 |080495b4| d | OBJECT| | |.data x_global_init |080495b8| D | OBJECT|00000004| |.data y_global_init |080495bc| d | OBJECT|00000004| |.data z_global |080495c0| D | OBJECT|00000004| |.data y_global_init |080495c4| d | OBJECT|00000004| |.data __bss_start |080495c8| A | NOTYPE| | |*ABS* _edata |080495c8| A | NOTYPE| | |*ABS* completed.5828 |080495c8| b | OBJECT|00000001| |.bss y_global_uninit |080495cc| b | OBJECT|00000004| |.bss x_global_uninit |080495d0| B | OBJECT|00000004| |.bss _end |080495d4| A | NOTYPE| | |*ABS*

Здесь собраны все символы обоих объектов, и все неопределённые ссылки были вычищены. Символы также были переупорядочены, чтобы одинаковые классы располагались вместе, и было добавлено несколько дополнительных сущностей, чтобы помочь операционной системе работать со всем этим добром как с исполняемой программой.

Для очистки вывода в UNIX можно убрать всё, что начинается с подчерка.

Дублирование символов

В предыдущем разделе мы уяснили, что если компоновщик не может найти определения для объявленного символа, то он выбросит ошибку. Что случится в том случае, если будет найдено два определения для символа во время линковки?

В Си++ вся просто – по стандарту у символа должно быть всегда одно определение (т.н. правило одного определения) секции 3.2 стандарта языка.

Для си всё менее ясно. У функции или инициализированной глобальной переменной всегда должно быть только одно определение. Но определение неинициализированной глобальной переменной может быть рассмотрено как предварительное. Си в таком случае позволяет (по крайней мере, не запрещает) разным файлам кода иметь свои предварительные определения для того же объекта.

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

В результате, UNIX компоновщик обычно не жалуется на дублирование дефиниций символа, по крайней мере, пока дублированный символ неинициализированная глобальная переменная (такая модель известна как ослабленная модель – relaxed ref/def model линковки). Если это вас беспокоит (а должно!) найдите в документации к своему компилятору ключ, который делает поведение более строгим. Например –fno-common для GNU компилятора заставляет помещать неинициализированные переменные в BSS сегмент, вместо генерации общих блоков.

Что делает операционная система

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

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

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

Для неинициализированных переменных ОС не будет копировать значений из памяти (т.к. их нет) и заполнит всё нулями. Кусок памяти, инициализированный 0 называют bss сегментом.

Начальное значение инициализированных переменных хранится на диске, в исполняемом файле; для неинициализированных переменных хранится их размер.


Заметьте, что мы всё это время говорим только о глобальных переменных и ни разу не упомянули локальные или динамически созданные объекты.

Эти данные не нуждаются в работе линкера, потому что время их жизни начинается с того момента, как запустится программа – задолго после того, как компоновщик закончит свою работу. Тем не менее, для полноты картины всё-таки укажем ещё раз

  • Локальные переменные располагаются на участке памяти, известном как стек, который растёт и уменьшается, когда начинает исполняться или заканчивает работу функция
  • Динамическая память выделяется на участке, известно как куча; выделением заведут функция malloc

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


Что делает компоновщик. Часть 2

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

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

Вообще, достаточно просто использовать один и тот же объектный файл для сборки разных программ, но гораздо лучше собрать сходные объектные файлы вместе и сделать библиотеку.

Статические библиотеки

Самая простая ипостась библиотеки – статическая. В предыдущем разделе оговаривалось, что можно просто разделять между программами один объектный файл. На самом деле статическая библиотека немногим более, чем просто объектный файл.

На UNIX системах статическая библиотека обычно генерируется командой ar, а сам библиотечный файл имеет расширение.a. Также обычно эти файлы начинаются с префикса lib и передаются линкеру с флагом –l, за которым следует имя библиотеки без префикса lib и без расширения (например, для файла libfred.a надо добавить -lfred).

Ar rcs libfile.a file.o gcc main.o libfile.a -o out.exe

Более сложный пример, пусть у нас имеются три файла

A.c int a_f(int a) { return a + 1; } b.c int b_f(int a) { return a + 1; } c.c int c_f(int a) { return a + 1; }

И главный файл

Abc.c #include int main() { int a = a_f(0); int b = a_f(1); int c = a_f(2); printf("%d %d %d", a, b, c); return 0; }

Соберём a.c, b.c и c.c в библиотеку libabc.a. Сначала скомпилируем все файл (можно и по-отдельности, вместе быстрее)

Gcc –g –O –c a.c b.c c.c abc.c

Получим четыре объектных файла. После этого соберём a, b и c в один файл

Ar rcs libabc.a a.o b.o c.o

и теперь можем скомпилировать программу

Gcc -o abc.exe libabc.a abc.o

Заметьте, что попытка собрать так

Gcc -o abc.exe abc.o libabc.a

приведёт к ошибке – компоновщик начнёт жаловаться на неразрешённые символы.

На windows статические библиотеки обычно имеют расширение.lib и генерируются утилитой LIB, но путаницу вносит то, что такое же расширение и у библиотек импорта, которые просто содержат список доступных в динамической библиотеке (dll) вещей.

Пока линкер проходит по коллекции объектных файлов, чтобы собрать их вместе, он составляет список ещё не разрешённых символов. После обработки списка всех явно объявленных объектов у компоновщика теперь есть ещё одно место, где можно поискать необъявленные символы – в библиотеке. Если неразрешённый объект находится в библиотеке, то он добавляется, точно как если бы пользователь указал его в командной строке.

Обратите внимание на уровень детализации объектов: если нужен какой-то конкретный символ, то добавляется весь объект, содержащий этот символ. Таким образом, линкер может попасть в ситуацию, когда он делает шаг вперёд и два назад, потому что новый объект, в свою очередь может содержать свои, неразрешённые символы.

Другая важная деталь – порядок событий. Библиотеки опрашиваются только после того, как была проведена нормальная компоновка, и они обрабатываются по порядку, слева направо. Это значит, что если библиотека требует символ, который был ранее в предыдущей подключённой библиотеке, то линкер не сможет его автоматически найти.

Пример должен помочь разобраться в этом более подробно. Пусть у нас имеются объектные файлы a.o, b.o и библиотеки libx.a, liby.b.

File a.o b.o libx.a liby.a
Object a.o b.o x1.o x2.o x3.o y1.o y2.o y3.o
Definitions a1, a2, a3 b1, b2 x11, x12, x13 x21, x22, x23 x31, x32 y11, y12 y21, y22 y31, y32
Undefined references b2, x12 a3, y22 x23, y12 y11 y21 x31

После обработки файлов a.o и b.o линкер разрешит ссылки b2 и a3, оставив неопределёнными x12 и y22. В этом месте линкер начинает проверять первую библиотеку libx.a и узнаёт, что может вытащить x1.o, в котором определён символ x12; сделав это, линкер получает в нагрузку неопределённые символы x23 и y12, объявленные в x1.o (т.о. в списке неопределённых значатся y22, x23 и y23).

Линкер всё ещё проверяет libx.a, поэтому без труда разрешает символ x23, вытащив его из x2.o библиотеки libx.a. Но этот x2.o добавляет y11 (который теперь состоит из y11, y22 и y12). Ни один из них далее не может быть разрешён с помощью библиотеки libx.a, поэтому линкер переходи к файлу liby.a.

Здесь происходит примерно то же самое, и компоновщик вытаскивает y1.o и y2.o. Первый добавляет y21, но он легко разрешается, так как уже вытащен на свет y2.o. Результатом всей работы становится то, что компоновщик смог разрешить все символы и достал почти все объектные файлы, которые будут помещены в конечный исполняемый файл.

Заметьте, что если бы b.o, например, содержало ссылку на y32, то всё пошло по другому сценарию. Обработка libx.a была бы такой же, но вот обработка liby.a вытащила y3.o, содержащий ссылку x31, которая определена в libx.a. Так как обработка libx.a уже закончена, то компоновщик бы выдал ошибку.

Это пример циклической зависимости двух библиотек libx и liby.

Разделяемые библиотеки

У популярных стандартных библиотек Си (обычно libc) есть очевидный недостаток – каждый исполняемый файл будет иметь свою копию одного и того же когда. Если каждая программа имеет копию printf, fopen и тому подобного, то много дискового пространства будет потрачено впустую.

Другой, менее очевидный недостаток заключается в том, что после статической компоновки код программы неизменен. Если кто-то найдёт и исправит баг в printf, то все программы, использующие эту библиотеку, нужно будет пересобрать.

Для того чтобы обойти эти проблемы, были внедрены разделяемы библиотеки (обычно они имеют расширение.so или.dll по Windows, или.dylib под Mac OS X). При работе с такими библиотеками линкер не обязан объединять все элементы в одну картинку. Вместо этого он оставляет что-то вроде долговой расписки и переносит выплату на тот момент, когда программа будет запущена.

Говоря короче: если линкер узнаёт, что неопределённый символ в разделяемой библиотеке, то он не добавляет определения в исполняемый файл. Вместо этого компоновщик записывает в программу имя символа и библиотеки, в которой он предполагаемо определён.

Во время исполнения программы операционная система определяет, что эти пропущенные биты линкуются “just in time” – во время выполнения. Перед запуском функции main уменьшенная версия линкера (часто это ld.so) проходит по спискам должников и доделывает финальную часть работы – вытаскивает код из библиотеки и собирает пазл.

Это значит, что ни у одной из исполняемых программ нет копии printf. Новая исправленная версия libc может просто подменить старую, и она будет подхвачена каждой из программ при новом запуске.

Есть и другое важное отличие динамической библиотеки от статической, и это отражается в степени детализации ссылок. Если определённый символ достаётся из разделяемой библиотеки (например, printf из libc), всё содержимое этой библиотеки отображается в адресное пространство. Это сильно отличается от статической библиотеки, из которой вытаскивается только тот объектный файл, который содержит определение объявленного символа.

Другими словами, разделяемая библиотека это результат работы компоновщика (а не просто собранные в кучу с помощью ar объектные файлы) с разрешёнными ссылками внутри объектов этого файла. Ещё раз: nm удачно это иллюстрирует. Для статической библиотеки nm покажет набор отдельных объектных файлов. Для разделяемой библиотеки liby.so укажет только неопределённый символ x31. Также, для нашего примера с порядком компоновки и циклической ссылкой, проблем не будет, потому что весь контент y3.o и x3.o так и так уже вытащен.

Есть также другой полезный инструмент ldd. Он показывает все разделяесые библиотеки, от которых зависит исполняемый файл или библиотека с информацией о том, где её можно найти. Чтобы программа могла удачно запуститься, нужно, чтобы все эти библиотеки были найдены, вместе со всеми их зависимостями (обычно, на UNIX системах загрузчик ищет библиотеки в списке папок, который хранится в переменной окружения LD_LIBRARY_PATH).

/usr/bin:ldd xeyes linux-gate.so.1 => (0xb7efa000) libXext.so.6 => /usr/lib/libXext.so.6 (0xb7edb000) libXmu.so.6 => /usr/lib/libXmu.so.6 (0xb7ec6000) libXt.so.6 => /usr/lib/libXt.so.6 (0xb7e77000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb7d93000) libSM.so.6 => /usr/lib/libSM.so.6 (0xb7d8b000) libICE.so.6 => /usr/lib/libICE.so.6 (0xb7d74000) libm.so.6 => /lib/libm.so.6 (0xb7d4e000) libc.so.6 => /lib/libc.so.6 (0xb7c05000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb7c01000) libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0xb7bff000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb7be8000) libdl.so.2 => /lib/libdl.so.2 (0xb7be4000) /lib/ld-linux.so.2 (0xb7efb000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7bdf000)

На Windows, например

Ldd C:\Windows\System32\rundll32.exe ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x77100000) KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x763a0000) KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x73e10000) apphelp.dll => /c/WINDOWS/system32/apphelp.dll (0x71ec0000) AcLayers.DLL => /c/WINDOWS/AppPatch/AcLayers.DLL (0x78830000) msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x74ef0000) USER32.dll => /c/WINDOWS/System32/USER32.dll (0x76fb0000) win32u.dll => /c/WINDOWS/System32/win32u.dll (0x74060000) GDI32.dll => /c/WINDOWS/System32/GDI32.dll (0x74b00000) gdi32full.dll => /c/WINDOWS/System32/gdi32full.dll (0x741e0000) SHELL32.dll => /c/WINDOWS/System32/SHELL32.dll (0x74fc0000) cfgmgr32.dll => /c/WINDOWS/System32/cfgmgr32.dll (0x74900000) windows.storage.dll => /c/WINDOWS/System32/windows.storage.dll (0x74390000) combase.dll => /c/WINDOWS/System32/combase.dll (0x76490000) ucrtbase.dll => /c/WINDOWS/System32/ucrtbase.dll (0x74100000) RPCRT4.dll => /c/WINDOWS/System32/RPCRT4.dll (0x76b50000) bcryptPrimitives.dll => /c/WINDOWS/System32/bcryptPrimitives.dll (0x74940000) powrprof.dll => /c/WINDOWS/System32/powrprof.dll (0x73c20000) advapi32.dll => /c/WINDOWS/System32/advapi32.dll (0x76ad0000) sechost.dll => /c/WINDOWS/System32/sechost.dll (0x76440000) shlwapi.dll => /c/WINDOWS/System32/shlwapi.dll (0x76d30000) kernel.appcore.dll => /c/WINDOWS/System32/kernel.appcore.dll (0x73c10000) shcore.dll => /c/WINDOWS/System32/shcore.dll (0x76c20000) profapi.dll => /c/WINDOWS/System32/profapi.dll (0x73c70000) OLEAUT32.dll => /c/WINDOWS/System32/OLEAUT32.dll (0x76e20000) msvcp_win.dll => /c/WINDOWS/System32/msvcp_win.dll (0x74080000) SETUPAPI.dll => /c/WINDOWS/System32/SETUPAPI.dll (0x766c0000) MPR.dll => /c/WINDOWS/SYSTEM32/MPR.dll (0x6cac0000) sfc.dll => /c/WINDOWS/SYSTEM32/sfc.dll (0x2380000) WINSPOOL.DRV => /c/WINDOWS/SYSTEM32/WINSPOOL.DRV (0x6f2f0000) bcrypt.dll => /c/WINDOWS/SYSTEM32/bcrypt.dll (0x73b70000) sfc_os.DLL => /c/WINDOWS/SYSTEM32/sfc_os.DLL (0x68e00000) IMM32.DLL => /c/WINDOWS/System32/IMM32.DLL (0x76d90000) imagehlp.dll => /c/WINDOWS/System32/imagehlp.dll (0x749a0000)

Причиной этого большего дробления связана с тем, что операционная система достаточно умная и вы можете дублировать дисковое пространство не только статическими библиотеками. Разные исполняемые процессы могут расшаривать также один сегмент кода (но не data/bss сегменты). Чтобы это сделать, вся библиотека должна быть отображена в один проход, чтобы все внутренние ссылки выстроились в один ряд: если один процесс вытащил a.o и c.o, а второй b.o и c.o, для операционной системы никакого совпадения не будет.

В типичной системе одновременно выполняется множество программ. Работа каждой программы зависит от множества функций, некоторые из которых входят в состав "стандартной" Си-библиотеки (например, printf() , malloc() , write() и т. д.).

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

Статическая компоновка Термин "статически скомпонованный" (statically linked) означает, что программа и некоторая библиотека были объединены с помощью компоновщика (linker) во время процесса компоновки. Таким образом, связь между программой и библиотекой является фиксированной и устанавливается во время процесса компоновки, т. е. до того, как программа будет работать. Кроме всего прочего, это также означает, можно изменить данную связь иначе, как посредством перекомпоновки программы с новой версией библиотеки.

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

Статически скомпонованные программы компонуются с архивами объектов (библиотеками ), которые обычно имеют расширение a. Примером такого набора объектов является стандартная Си-библиотека libc.a.

Динамическая компоновка Термин "динамически скомпонованный" (dynamically linked) означает, что программа и некоторая библиотека не были объединены с помощью компоновщика во время процесса компоновки. Вместо этого, компоновщик помещает информацию в исполняемый файл, который, в свою очередь, сообщает загрузчику, в каком разделяемом объектном модуле расположен код и какой динамический компоновщик (runtime linker) должен использоваться для поиска и компоновки ссылок. Это означает, что связь между программой и разделяемым объектом устанавливается во время выполнения программы, а именно, в самом начале выполнения производится поиск и компоновка необходимых разделяемых объектов.

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

Динамически скомпонованные программы компонуются с разделяемым объектами с расширением so. Примером такого объекта является разделяемая стандартная Си-библиотека libc.so.

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

Добавление кода в процессе работы программы При таком подходе вызываемые из программы функции будут определены только на этапе исполнения. Это предоставляет дополнительные возможности.

Рассмотрим пример работы драйвера диска. Драйвер запускается, тестирует оборудование и обнаруживает жёсткий диск. Затем драйвер динамически загружает модуль io-blk, предназначенный для обработки дисковых блоков, т.к. было обнаружено блок-ориентированное устройство. После того как драйвер получает доступ к диску на блочном уровне, он обнаруживает на диске два раздела: раздел DOS и раздел QNX4. Чтобы не увеличивать размер драйвера жёсткого диска, в него вообще не включаются драйверы файловых систем. Во время работы системы драйвер может обнаружить эти два раздела (DOS и QNX4) и только после этого загрузить соответствующие модули файловых систем fs-dos.so и fs-qnx4.so.

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

Как используются разделяемые объекты Для того чтобы понять, как программа использует разделяемые объекты, необходимо сначала рассмотреть формат исполняемого модуля, а затем последовательность тех стадий, через которые программа проходит при запуске. Формат ELF В ОС QNX Neutrino используется так называемый двоичный формат исполняемых и компонуемых модулей (Executable and Linkable Format, ELF), который в настоящее время принят в системах SVR4 Unix. Формат ELF не только упрощает создание разделяемых библиотек, но также расширяет возможности динамической загрузки модулей во время работы программы.

На рис. 7.1 показан ELF-файл в двух представлениях: представление компоновки и представление исполнения. Представление компоновки, используемое в процессе компоновки программы или библиотеки, касается секций (sections) внутри объектного файла. Секции содержат большую часть информации этого файла: данные, инструкции, настроечная информация, идентификаторы, отладочная информация и т. д. Представление исполнения, используемое при выполнении программы, касается сегментов (segments) .

В процессе компоновки программа или библиотека строится посредством слияния секций, имеющих одинаковые атрибуты, и преобразования их в сегменты. Как правило, все секции, содержащие данные, которые предназначены для исполнения или "только для чтения", компонуются в один сегмент text , а данные и BSS компонуются в сегмент data . Эти сегменты называются загрузочными сегментами (load segments) , потому что они должны быть загружены в память при создании процесса. Другие секции, как, например, информация об идентификаторах и отладочная информация, объединяются в т. н. незагружаемые сегменты (nonload segments) .

Я хочу точно понять, на какую часть компилятора программы просматривается и на что ссылается компоновщик. Поэтому я написал следующий код:

#include using namespace std; #include void FunctionTemplate (paramType val) { i = val } }; void Test::DefinedCorrectFunction(int val) { i = val; } void Test::DefinedIncorrectFunction(int val) { i = val } void main() { Test testObject(1); //testObject.NonDefinedFunction(2); //testObject.FunctionTemplate(2); }

У меня есть три функции:

  • DefinedCorrectFunction - это нормальная функция, объявленная и определенная правильно.
  • DefinedIncorrectFunction - эта функция объявлена ​​правильно, но реализация неверна (отсутствует;)
  • NonDefinedFunction - только объявление. Нет определения.

    • FunctionTemplate - шаблон функции.

    Теперь, если я скомпилирую этот код, я получаю ошибку компилятора для отсутствующего ";" в DefinedIncorrectFunction.
    Предположим, я исправить это, а затем прокомментировать testObject.NonDefinedFunction(2). Теперь я получаю ошибку компоновщика. Теперь закомментируйте testObject.FunctionTemplate(2). Теперь я получаю ошибку компилятора для отсутствующих ";".

Для шаблонов функций я понимаю, что они не тронуты компилятором, если они не вызываются в коде. Итак, недостающие ";" не жалуется компилятором, пока я не вызвал testObject.FunctionTemplate(2).

Для testObject.NonDefinedFunction(2) компилятор не жаловался, но компоновщик сделал. Насколько я понимаю, весь компилятор должен был знать, что объявлена ​​функция NonDefinedFunction. Он не заботился об осуществлении. Затем линкер жаловался, потому что не смог найти реализацию. Пока все хорошо.

Итак, я не совсем понимаю, что именно делает компилятор и что делает компоновщик. Мое понимание компонентов компоновщика ссылок со своими вызовами. Так что, когда NonDefinedFunction называется, он ищет скомпилированную реализацию NonDefinedFunction и жалуется. Но компилятор не заботился о реализации NonDefinedFunction, но это делалось для DefinedIncorrectFunction.

Я бы очень признателен, если кто-нибудь сможет объяснить это или дать некоторую ссылку.

8 ответов

Функция компилятора заключается в том, чтобы скомпилировать написанный вами код и преобразовать его в файлы объектов. Поэтому, если вы пропустили; или использовали переменную undefined, компилятор будет жаловаться, потому что это синтаксические ошибки.

Если компиляция выполняется без каких-либо сбоев, создаются объектные файлы . Объектные файлы имеют сложную структуру, но в основном содержат пять вещей

  • Заголовки - информация о файле
  • Код объекта - код в машинном языке (этот код не может работать сам по себе в большинстве случаев)
  • Информация о переезде. Каким частям кода необходимо будет изменить адреса при фактическом выполнении.
  • Таблица символов . Символы, на которые ссылается код. Они могут быть определены в этом коде, импортированы из других модулей или определены компоновщиком
  • Отладочная информация - используется отладчиками

Компилятор компилирует код и заполняет таблицу символов каждым символом, с которым он сталкивается. Символы относятся к переменным и функциям. Ответ на Этот вопрос объясняет таблицу символов.

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

Точка примечания

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

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

Итак, в вашем конкретном случае -

  • DefinedIncorrectFunction() - компилятор получает определение функции и начинает компилировать его для создания объектного кода и вставки соответствующей ссылки в таблицу символов. Ошибка компиляции из-за ошибки синтаксиса, поэтому компилятор прерывается с ошибкой.
  • NonDefinedFunction() - компилятор получает декларацию, но не имеет определения, поэтому добавляет запись в таблицу символов и помещает компоновщик для добавления соответствующих значений (поскольку компоновщик обрабатывает кучу объектных файлов, возможно, это определение присутствует в некоторых другой файл объекта). В вашем случае вы не указываете какой-либо другой файл, поэтому компоновщик прерывается с ошибкой undefined reference to NonDefinedFunction , потому что он не может найти ссылку на соответствующую запись в таблице символов.

Чтобы понять это, еще раз скажем, что ваш код структурирован следующим образом

#include #include class Test { private: int i; public: Test(int val) {i=val ;} void DefinedCorrectFunction(int val); void DefinedIncorrectFunction(int val); void NonDefinedFunction(int val); template void FunctionTemplate (paramType val) { i = val; } };

Файл try.cpp

#include "try.h" void Test::DefinedCorrectFunction(int val) { i = val; } void Test::DefinedIncorrectFunction(int val) { i = val; } int main() { Test testObject(1); testObject.NonDefinedFunction(2); //testObject.FunctionTemplate(2); return 0; }

Давайте сначала скопируем и собираем код, но не свяжем его

$g++ -c try.cpp -o try.o $

Этот шаг протекает без каких-либо проблем. Таким образом, у вас есть объектный код в try.o. Попробуйте и соедините его.

$g++ try.o try.o: In function `main": try.cpp:(.text+0x52): undefined reference to `Test::NonDefinedFunction(int)" collect2: ld returned 1 exit status

Вы забыли определить Test:: NonDefinedFunction. Пусть определите его в отдельном файле.

Файл-try1.cpp

#include "try.h" void Test::NonDefinedFunction(int val) { i = val; }

Скомпилируем его в объектный код

$ g++ -c try1.cpp -o try1.o $

Снова это успешно. Попробуем связать только этот файл

$ g++ try1.o /usr/lib/gcc/x86_64-redhat-linux/4.4.5/../../../../lib64/crt1.o: In function `_start": (.text+0x20): undefined reference to `main" collect2: ld returned 1 exit status

Нет основной так выигранной; t link!!

Теперь у вас есть два отдельных объектных кода, в которых есть все необходимые компоненты. Просто передайте ОБОИХ из них в компоновщик, и пусть это сделает остальные

$ g++ try.o try1.o $

Нет ошибок! Это связано с тем, что компоновщик находит определения всех функций (даже если они разбросаны в разных объектных файлах) и заполняет пробелы в объектных кодах соответствующими значениями

Скажите, что вы хотите съесть какой-то суп, поэтому отправляйтесь в ресторан.

Вы ищете меню для супа. Если вы не найдете его в меню, вы покидаете ресторан. (вроде компилятора, жалующегося на то, что он не смог найти функцию). Если вы его найдете, что вы делаете?

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

Я считаю, что это ваш вопрос:

Где я запутался, когда компилятор жаловался на DefinedIncorrectFunction. Он не искал реализацию NonDefinedFunction, но прошел через DefinedIncorrectFunction.

Компилятор попытался разобрать DefinedIncorrectFunction (потому что вы предоставили определение в этом исходном файле), и произошла синтаксическая ошибка (отсутствовала точка с запятой). С другой стороны, компилятор никогда не видел определения для NonDefinedFunction , потому что в этом модуле просто не было кода. Возможно, вы указали определение NonDefinedFunction в другом исходном файле, но компилятор этого не знает. Компилятор просматривает только один исходный файл (и его включенные файлы заголовков) за раз.

Компилятор проверяет, соответствует ли исходный код языку и соответствует семантике языка. Вывод компилятора - это объектный код.

Компоновщик связывает различные объектные модули вместе, чтобы сформировать exe. Определения функций расположены в этой фазе, и на этом этапе добавляется соответствующий код для их вызова.

Компилятор компилирует код в виде единиц перевода . Он скомпилирует весь код, который включен в исходный файл.cpp ,
DefinedIncorrectFunction() определяется в вашем исходном файле, поэтому компилятор проверяет его на корректность языка.
NonDefinedFunction() имеет какое-либо определение в исходном файле, поэтому компилятору не нужно его компилировать, если определение присутствует в каком-то другом исходном файле, функция будет скомпилирована как часть этой единицы перевода, а позже линкер свяжет к нему, если на этапе связывания определение не найдено компоновщиком, тогда оно вызовет ошибку связывания.

Что делает компилятор, и что делает компоновщик, зависит от реализация: правовая реализация может просто хранить токенизированные источник в "компиляторе" и делать все в компоновщике. Современные реализации ставят все больше и больше на компоновщик, для лучшая оптимизация. И многие ранние реализации шаблонов не даже посмотрите код шаблона до тех пор, пока время ссылки, кроме соответствующих фигурных скобок достаточно знать, где шаблон закончился. С точки зрения пользователя, вас больше интересует, требует ли ошибка "диагностика" (которая может быть выбрана компилятором или компоновщиком) или undefined.

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

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

Это несколько изменено в таких случаях, как встроенные функции, где вы разрешено повторять определение в каждой единицы перевода и измененный шаблонами, поскольку многие ошибки не могут быть обнаружены до тех пор, пока конкретизации. В случае шаблонов стандартный лист реализаций большая свобода: по крайней мере, компилятор должен проанализируйте шаблон достаточно, чтобы определить, где заканчивается шаблон. добавленные стандартные вещи, такие как typename , тем не менее, позволяют значительно больше синтаксический анализ перед созданием. Однако в зависимых контекстах некоторые ошибки не могут быть обнаружены до создания экземпляра, что может место во время компиляции или время ссылки; ранние реализации предпочтительная компоновка времени ссылки; время компиляции сегодня, и используется VС++ и g++.

[из методы]

Определение 9.22 Компоновщик (редактор связей) " это программа, предназначенная для связывания между собой объектных файлов, порождаемых компилятором, и файлов библиотек, входящих в состав системы программирования.

Объектный файл не может быть запущен до тех пор, пока все модули и секции не будут в нем увязаны между собой. Результатом работы компоновщика является исполняемый файл. Этот файл включает в себя текст программы на языке машинных кодов. При попытке создать исполняемый файл компоновщик может вывести сообщение об ошибке, если он не обнаружил какого-либо компонента.

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

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

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

Компоновщик (также реда́ктор свя́зей, линкер - от англ. link editor, linker) - программа, которая производит компоновку - принимает на вход один или несколько объектных модулей и собирает по ним исполнимый модуль.

Для связывания модулей компоновщик использует таблицы имён, созданные компилятором в каждом из объектных модулей. Такие имена могут быть двух типов:

Определённые или экспортируемые имена - функции и переменные, определённые в данном модуле и предоставляемые для использования другим модулям

Неопределённые или импортируемые имена - функции и переменные, на которые ссылается модуль, но не определяет их внутри себя

Работа компоновщика заключается в том, чтобы в каждом модуле разрешить ссылки на неопределённые имена. Для каждого импортируемого имени находится его определение в других модулях, упоминание имени заменяется на его адрес.

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


11. Принципы функционирования систем программирования. Функции текстовых редакторов в системах программирования. Компилятор как составная часть системы программирования.

Принципы функционирования систем программирования

Функции текстовых редакторов в системах программирования

Текстовый редактор в системе программирования - это программа, позволяю­щая создавать, изменять и обрабатывать исходные тексты программ на языках высокого уровня.

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

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

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

Можно сказать, что с появлением интегрированных сред разработки ушло в про­шлое то время, когда разработчики исходных текстов вынуждены были перво­начально готовить тексты программ на бумаге с последующим вводом их в ком­пьютер. Процессы написания текстов и собственно создание программного обеспечения стали единым целым.

Интегрированные среды разработки оказались очень удобным средством. Они стали завоевывать рынок средств разработки программного обеспечения. А с их развитием расширялись и возможности, предоставляемые разработчику в среде текстового редактора. Со временем появились средства пошаговой отладки про­грамм непосредственно по их исходному тексту, объединившие в себе возможно­сти отладчика и редактора исходного текста. Другим примером может служить очень удобное средство, позволяющее графически выделить в исходном тексте программы все лексемы исходного языка по их типам - оно сочетает в себе воз­можности редактора исходных текстов и лексического анализатора компиля­тора.

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

Компилятор как составная часть системы программирования

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

От первых этапов развития систем программирования вплоть до появления интегрированных сред разработки пользователи (разработчики исходных про­грамм) всегда так или иначе имели дело с компилятором. Они непосредственно взаимодействовали с ним как с отдельным программным модулем.

Сейчас, работая с системой программирования, пользователь, как правило, име­ет дело только с ее интерфейсной частью, которую обычно представляет тексто­вый редактор с расширенными функциями. Запуск модуля компилятора и вся его работа происходят автоматически и скрытно от пользователя - разработ­чик видит только конечные результаты выполнения компилятора. Хотя многие современные системы программирования сохранили прежнюю возможность не­посредственного взаимодействия разработчика с компилятором (это и Makefile, и так называемый «интерфейс командной строки»), но пользуется этими средст­вами только узкий круг профессионалов. Большинство пользователей систем программирования сейчас редко непосредственно сталкиваются с компилято­рами.

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

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

Компоновщик. Назначение и функции компоновщика.

12. Компоновщик. Назначение и функции компоновщика

Компоновщик (или редактор связей) предназначен для связывания между собой объектных файлов, порождаемых компилятором, а также файлов библиотек, входящих в состав системы программирования 1 .

Объектный файл (или набор объектных файлов) не может быть исполнен до тех пор, пока все модули и секции не будут в нем увязаны между собой. Это и делает редактор связей (компоновщик). Результатом его работы является единый файл (часто называемый «исполняемым файлом»), который содержит весь текст ре­зультирующей программы на языке машинных кодов. Компоновщик может по­рождать сообщение об ошибке, если при попытке собрать объектные файлы в единое целое он не смог обнаружить какой-либо необходимой составляющей.

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

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

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

13. Загрузчики и отладчики. Функции загрузчика

Большинство объектных модулей в современных системах программирования строятся на основе так называемых относительных адресов. Компилятор, порож­дающий объектные файлы, а затем и компоновщик, объединяющий их в единое целое, не могут знать точно, в какой реальной области памяти компьютера будет располагаться программа в момент ее выполнения. Поэтому они работают не с реальными адресами ячеек ОЗУ, а с некоторыми относительными адресами. Та­кие адреса отсчитываются от некоторой условной точки, принятой за начало области памяти, занимаемой результирующей программой (обычно это точка начала первого модуля программы).

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

Однако загрузчик не всегда является составной частью системы программирова­ния, поскольку выполняемые им функции очень зависят от архитектуры целе­вой вычислительной системы, в которой выполняется результирующая программа, созданная системой программирования. На первых этапах развития ОС загруз­чики существовали в виде отдельных модулей, которые выполняли трансляцию адресов и готовили программу к выполнению - создавали так называемый «об­раз задачи». Такая схема была характерна для многих ОС (например, для ОСРВ на ЭВМ типа СМ-1, ОС RSX/11 или RAFOS на ЭВМ типа СМ-4 и т. п. ). Образ задачи можно было сохранить на внешнем носителе или же создавать его вновь всякий раз при подготовке программы к выполнению.

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

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

Еще одним модулем системы программирования, функции которого тесно связа­ны с выполнением программы, является отладчик.

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


  • последовательное пошаговое выполнение результирующей программы на ос­
    нове шагов по машинным командам или по операторам входного языка;

  • выполнение результирующей программы до достижения ею одной из задан­
    ных точек останова (адресов останова);

  • выполнение результирующей программы до наступления некоторых заданных
    условий, связанных с данными и адресами, обрабатываемыми этой програм­
    мой;

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

  • появлением интегрированных сред разработки;

  • появление возможностей аппаратной поддержки средств отладки во многих
    вычислительных системах.
Первый из этих шагов дал возможность разработчикам программ работать не в терминах машинных команд, а в терминах исходного языка программирова­ния, что значительно сократило трудозатраты на отладку программного обес- печения. При этом отладчики перестали быть отдельными модулями и стал] интегрированной частью систем программирования, поскольку они должны был] теперь поддерживать работу с таблицами идентификаторов (см. раздел «Табли цы идентификаторов. Организация таблиц идентификаторов», глава 15) и вы поднять задачу, обратную идентификации лексических единиц языка (см. разде. «Семантический анализ и подготовка к генерации кода», глава 14). Это связано тем, что в такой среде отладка программы идет в терминах имен, данных поль зователем, а не в терминах внутренних имен, присвоенных компилятором. Сс ответствующие изменения потребовались также в функциях компиляторов компоновщиков, поскольку они должны были включать таблицу имен в соста объектных и исполняемых файлов для ее обработки отладчиком.

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

14. Библиотеки подпрограмм как составная часть систем программирования

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

С точки зрения системы программирования, библиотеки подпрограмм состою из двух основных компонентов. Это собственно файл (или множество файло] библиотеки, содержащий объектный код, и набор файлов описаний функций, по, программ, констант и переменных, составляющих библиотеку.

15. Лексический анализ «на лету». Система подсказок и справок.

Дополнительные возможности систем программирования

Лексический анализ «на лету». Система подсказок и справок

Лексический анализ «на лету» - это функция текстового редактора в составе системы программирования. Она заключается в поиске и выделении лексем вход­ного языка в тексте программы непосредственно в процессе ее создания разра­ботчиком.

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

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

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

Следующей сервисной возможностью, предоставляемой разработчику системой программирования за счет лексического анализа «на лету», является возможность обращения разработчика к таблице идентификаторов в ходе подготовки исход­ного текста программы. Разработчик может дать компилятору команду найти нужную ему лексему в таблице. Поиск может выполняться по типу или по ка­кой-то части информации лексемы (например, по нескольким первым буквам). Причем поиск может быть контекстно-зависимым - система программирова­ния предоставит разработчику возможность найти лексему именно того типа, который может быть использован в данном месте исходного текста. Кроме самой, лексемы разработчику может быть предоставлена некоторая информация о ней - например, типы и состав формальных параметров для функции, перечень дос­тупных методов для типа или экземпляра класса. Это опять же облегчает труд разработчика, поскольку избавляет его от необходимости помнить состав функ­ций и типов многих модулей (прежде всего, библиотечных) или обращаться лишний раз к документации и справочной информации.

Лексический анализ «на лету» - мощная функция, значительно облегчающая труд, связанный с подготовкой исходного текста. Она входит не только в состав многих систем программирования, но также и в состав многих текстовых редак­торов, поставляемых отдельно от систем программирования (в последнем случае она позволяет настроиться на лексику того или иного языка).

Другой удобной сервисной функцией в современных системах программирова­ния является система подсказок и справок. Как правило, она содержит три ос­новные части:


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

  • подсказку по работе с самой системой программирования;

  • справку о функциях библиотек, входящих в состав системы программирова­
    ния.
Система подсказок и справок в настоящее время является составной частью мно­гих прикладных и системных программ. Как правило, она поддерживается соот­ветствующими утилитами ОС. Поэтому, кроме всего прочего, многие системы программирования включают в свой состав сервисные функции, позволяющие создавать и дополнять систему подсказок и справок. Это делается таким обра­зом, чтобы разработчик мог создавать и распространять вместе со своими при­кладными программами соответствующие им подсказки и справки.

16.Разработка программ в архитектуре «клиент-сервер»

Структура приложения, построенного в архитектуре «клиент - сервер».

Распространение динамически подключаемых библиотек и ресурсов прикладных программ привело к ситуации, когда большинство прикладных программ стало представлять собой не единый программный модуль, а набор сложным образом взаимосвязанных между собой компонентов. Многие из этих компонентов либо входили в состав ОС, либо же требовалась их поставка и установка от других разработчиков, которые очень часто могли быть никак не связаны с разработчи­ками самой прикладной программы.

При этом среди всего множества компонентов прикладной программы можно было выделить две логически цельные составляющие: первая - обеспечивающая «нижний уровень» работы приложения, отвечающая за методы хранения, досту­па и разделения данных; вторая - организующая «верхний уровень» работы приложения, включающий в себя логику обработки данных и интерфейс пользо­вателя.

Первая составляющая, как правило, представляла собой набор компонентов сто­ронних разработчиков. Часто она так или иначе была связана с доступом к базам данных, которые могли предусматривать достаточно сложную организацию. Для работы ее компонентов требовалось наличие высокопроизводительной вычисли­тельной системы.

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

Тогда сложилось понятие приложения, построенного на основе архитектуры «клиент-сервер». В первую (серверную) составляющую такого приложения от­носят все методы, связанные с доступом к данным. Чаще всего их реализует сер-

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

Кроме того, со временем на рынке СУБД стали доминировать несколько наибо­лее известных компаний-производителей. Они предлагали стандартизованные интерфейсы для доступа к создаваемым ими СУБД. На них, в свою очередь, ста­ли ориентироваться и разработчики прикладных программ. Такая ситуация оказала влияние и на структуру систем программирования. Мно­гие из них стали предлагать средства, ориентированные на создание приложений в архитектуре «клиент-сервер». Как правило, эти средства поставляются в соста­ве системы программирования и поддерживают возможность работы с широким диапазоном известных серверов данных через один или несколько доступных интерфейсов обмена данными. Разработчик прикладной программы выбирает одно из доступных средств плюс возможный тип сервера (или несколько воз- : можных типов), и тогда его задача сводится только к созданию клиентской части, ; приложения, построенной на основе выбранного интерфейса. Создав клиентскую часть, разработчик может далее использовать и распростра­нять ее только в комплексе с соответствующими средствами из состава системы программирования. Интерфейс обмена данными обычно входит в состав систе­мы программирования. Большинство систем программирования предоставляют возможность распространения средств доступа к серверной части без каких-либо дополнительных ограничений.

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

Более подробно об организации приложений на основе архитектуры «клиент-сервер» можно узнать в .