LINKER - Cбopщик пepeмeщaeмыx пpoгpaмм

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

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

В одной из своих старых прог я делал по другому: в начале библиотеки вставлял таблицу входных точек, создавая её командами DW. Это было простое позднее связывание, a'la динамическая линковка. Ни у кого на агате таких решений не видел. Но это требует привязки библиотеки к конкретному адресу. Зато программу и библиотеку можно существенно модифицировать по отдельности друг от друга.

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

Известный - потому что был почти на всех системных дисках с ДОК ("Ассемблер"), неизвестный - потому что ни в одной коллекции я не видел следов его использования. Сам я его тоже не мог использовать, потому что не знал - как? ИКП у меня не было, а инструкция к LINKER была только в ИКП-7-840.

Я даже пытался его декомпилировать и разобраться в логике работы. Но результатов (уже не помню - почему) не было. Наверное, свои велосипеды оказались проще.
При разборе коллекции Лёвина (автор СУБД Паруса/Карата/Эврика и Шахмат/Шашек) обнаружилась как инструкция к Linker так и его исходники.

Некоторое время назад я приступил к его неспешному ковырянию.
Выяснилось, что сам по себе линкер почти работает, но только в старых версиях Школьницы. Судя по всему, те, кто записывал его на диски с ИКП, не пытались проверить работоспособность.

Тут вот какая штука: Цикоза (руководитель группы авторов Школьницы, LINKER родом оттуда же), стремился сохранять совместимость между разными версиями ДОК, в том числе по программному интерфейсу. Но делалось это немного коряво: при компиляции ДОК добивались того, чтобы ДОКУМЕНТИРОВАННЫЕ входные точки и таблицы аргументов драйверов файловой системы и дисководов совпадали. А вот недокументированные - как повезёт. Linker зачем-то использует входную точку процедуры PUTTSL (мне пока не ясно - зачем она ему?), которая в ИКП-шном ДОК уехала на пару кб в сторону.

Но даже подправив этот косяк (а заодно и сравнив работу в старой версии Школьницы) я не смог добиться корректной сборки загружаемого файла. И над этим я ещё буду работать.
А вот компиляция программ в так называемый Перемещаемый формат (который LINKER ожидает на входе) выполняется ДОК успешно. И это весьма радует.

С другой стороны: ассемблер Громова, к сожалению (проверил версии 1.0 и 5.0), при указании параметра R, хотя и собирает Перемещаемый файл, но таблица меток там записывается ... не, не так. Вместо таблицы меток записывается мусор :((. И это весьма огорчает. Тем более исходников громовского ассемблера у меня нет.

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

1) По каким смещениям находятся абсолютные адреса (например, аргумент команды JMP). Эти адреса линкер пересчитает при сборке окончательного проекта, подставив их фактические значения.

2) Какие адреса были неопределены и их следует подставить из другой библиотеки.

3) Какие адреса были известны и их следует использовать для настройки другой библиотеки.

Сам механизм импорта/экспорта адресов широчайше используется во всех современных ОС. Причем в двух видах: как для связывания кода на этапе компиляции, так и для связывания на этапе загрузки. Всем известные DLL- файлы -  ни что иное, как сильно развившийся аналог R-файлов агата (хотя, конечно, сама эта идея старше как Агата так и всех современных ОС).

На данный момент мне удалось разобрать формат R-файлов, осталось выловить ошибки в LINKER'e.

Продолжаем жрать вкусный кактус :)

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

Авторы ИКП-шной сборки ДОК опять что-то забыли. Но теперь не пару команд, а целый цикл инициализации.

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

Так вот единственная популярная ДОС, которая всё это кое как делает - это ДОС3.3. Она - самая сложная (пожалуй, сложнее только спрайт-ОС, ну и ONIX, хотя твёрдо не уверен). Про BTK сказать сложно, Школьница, хотя и может оперировать с фрагментами файлов, но фрагмент - только 1 байт, не больше. Всё остальное, что как-то читает файлы, как правило, может только прочитать весь файл за раз.

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

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

Вот.

У Школьницы регион FCB находится примерно в адресах $403..$4FF.

У канонично-семёрочного ДОК фрагмент инициализации, занимающийся очисткой FCB, начинается с адреса $2753, где уютно сидит примерно такой код:

275E -   A9 07 ..   ")."    LDA   #07
2760 -   8D 00 04   "..."   STA   0400
2763 -   A9 90 ..   ")."    LDA   #90
2765 -   8D 01 04   "..."   STA   0401
2768 -   A9 7F ..   ")ъ"    LDA   #7F
276A -   8D 02 04   "..."   STA   0402
276D -   A9 00 ..   ")."    LDA   #00
276F -   A2 07 ..   ""."    LDX   #07    
2771 -   9D B0 03   ".0."   STA   03B0, X
2774 -   CA .. ..   "J"     DEX   
2775 -   10 FA ..   ".З"    BPL   2771
2777 -   A2 03 ..   ""."    LDX   #03        
2779 -   9D 00 04   "..."   STA   0400, X    
277C -   E8 .. ..   "Х"     INX   
277D -   D0 FA ..   "PЗ"    BNE   
277F -   EE B3 03   "Н3."   INC   03B3
2782 -   A9 43 ..   ")c"    LDA   #43
2784 -   8D E7 1B   ".Г."   STA   1BE7
2787 -   A9 27 ..   ")."    LDA   #27
2789 -   8D E8 1B   ".Х."   STA   1BE8
278C -   A9 21 ..   ")."    LDA   #21
278E -   8D E4 1B   ".Д."   STA   1BE4
2791 -   AE 00 0B   "..."   LDX   0B00
2794 -   8E 00 B0   "..0"   STX   B000
2797 -   20 37 0B   "..."   JSR   0B37
279A -   B9 17 0F   "9.."   LDA   0F17, Y
279D -   20 4B B4   ".k4"   JSR   B44B
27A0 -   A5 4B ..   "%k"    LDA   4B
27A2 -   8D B6 B4   ".64"   STA   B4B6
27A5 -   4C 00 1E   "l.."   JMP   1E00

Тут мы видим сброс всяких структур, в том числе $403..$4FF. Дальше идёт установка текущего дисковода и кой что ещё.

А что у нас в ИКП-7 ?

274F -   A5 4D ..   "%m"    LDA   4D
2751 -   8D 33 20   ".Ё."   STA   2033
2754 -   8D 25 20   "..."   STA   2025
2757 -   20 64 1B   ".д."   JSR   1B64
275A -   A5 4B ..   "%k"    LDA   4B
275C -   8D FF AF   ".Ъ/"   STA   AFFF
275F -   A9 07 ..   ")."    LDA   #07
2761 -   8D 00 04   "..."   STA   0400
2764 -   A9 90 ..   ")."    LDA   #90
2766 -   8D 01 04   "..."   STA   0401   
2769 -   A9 7F ..   ")ъ"    LDA   #7F
276B -   8D 02 04   "..."   STA   0402
276E -   A9 00 ..   ")."    LDA   #00
2770 -   8D EE 04   ".Н."   STA   04EE
2773 -   AC B3 03   ",3."   LDY   03B3
2776 -   A2 07 ..   ""."    LDX   #07
2778 -   9D B0 03   ".0."   STA   03B0, X
277B -   CA .. ..   "J"     DEX   
277C -   10 FA ..   ".З"    BPL   2778
277E -   8C B3 03   ".3."   STY   03B3
2781 -   A9 3F ..   ")."    LDA   #3F
2783 -   8D E7 1B   ".Г."   STA   1BE7
2786 -   A9 27 ..   ")."    LDA   #27
2788 -   8D E8 1B   ".Х."   STA   1BE8
278B -   A9 21 ..   ")."    LDA   #21
278D -   8D E4 1B   ".Д."   STA   1BE4
2790 -   4C 00 1E   "l.."   JMP   1E00

Похоже ?
Да. Но регион 403..4FF почистить забыли :(
А, не, не забыли:

276E -   A9 00 ..   ")."    LDA   #00
2770 -   8D EE 04   ".Н."   STA   04EE

Эта парочка команд вообще-то чистит как раз таки первый FCB. Значит не забыли!
Но не подумали о том, что их там больше одного. На самом деле их MAXFILES - содержимое ячейки $400.

Вообще-то тут ещё нет установки B001 - там в ИКП номер дисковода, но это есть в другом месте:

3B69 -   A5 55 ..   "%u"    LDA   55
3B6B -   99 A3 B3   ".#3"   STA   B3A3, Y
3B6E -   C8 .. ..   "H"     INY   
3B6F -   8C 01 B0   "..0"   STY   B001       <==
3B72 -   84 B4 ..   ".4"    STY   B4
3B74 -   8C B3 03   ".3."   STY   03B3
3B77 -   C0 04 ..   "@."    CPY   #04
3B79 -   90 1C ..   ".."    BCC   3B97
3B7B -   4C 37 3B   "l.."   JMP   3B37

это, конечно, не весь код инициализации. Важно другое - ну тут тоже нет очистки $403..$4FF. И вообще его нигде нет. Заполните этот регион любым мусором и после загрузки ДОК увидите его на месте. Я попал на это в ИКП-7 и позднее убедился в том же для ИКП-9.

В общем-то это всё влияет только на группу операций fopen/fclose (в системе имён Школьницы это OPEN/SHUTFILE), компилятор ассемблера, например, их не использует, равно как и текстовый редактор. Они работают сразу с LOAD/SAVE - чтение/запись файла целиком.

Ну ладно, не инициализировали регион, он забит мусором - значит ДОС на запрос открытия файла скажет "нет свободных буферов" (NOFRBUFS). Есть у неё такой код ошибки. Но это было бы слишком просто. И скучно.

Чтобы не было скучно, авторы LINKER'а подключают к ДОС свой обработчик ошибок. Но они забыли, что при возникновении ошибок не надо суетится и закрывать последний открытый файл. Потому что он может быть и не открыт, если ошибка произошла во время исполнения fopen. И вот в этот момент ДОС и пытается закрыть файл, который никто не открывал. Она бы не пыталась этого делать, если бы $403..$4FF был чистым.

Но там мусор, и снежный ком нарастает: в дескрипторе файла есть поле с номером дисковода, там мусор, драйвер дисковода не проверяет номер дисковода (какая незадача!),  а так как драйвер двухстандартный (140+840кб), то неизвестный номер имеет неизвестный обработчик ..... всё заканчивается "программа выполнила недопустимую операцию......." BRK, короче. Хотя, конечно, как повезёт. Зависит от первоначального мусора.

Да... Это просто песня.
Сразу вопросы возникают, как у разработчиков хранились исходники, если из побитых файлов собирались официальные ИКП, и как они тестировали софт, если даже в ДОС такие баги.
Я правильно понимаю, что в какой-то момент разработка системного софта была передана из Новосибирска в Москву?
Может, после передачи от одной команды разработчиков к другой все эти баги полезли?

И интересно про формат R. Вроде на Apple их было 2: один под DOS 3.3, другой под ProDOS. Вот тут кусочек описания для DOS 3.3, но без словаря символов http://apple2.org.za/gswv/a2zine/faqs/Csa2DOSMM.html

Byte   Meaning 
----   ------- 
$00-01 Original program load address 
$02-03 File length (program image + relocation dictionary) 
$04-05 Length of program image alone (not including relocation 
       dictionary) 
$06-xx Program image 
$xx-yy Relocation dictionary 

А тут ftp://ftp.apple.asimov.net/pub/apple_II … Manual.pdf на 228 странице описание для ProDOS, с форматом словаря.

Что нибудь общее с Агатовским форматом есть?

Маленько крыша едет, но раз уж начал и почти процентов 80 сделал, то стоит всё таки закончить.

Короче: грустно.

LINKER - замороченная прога, но бывает замороченность красивая и/или нужная, а бывает наоборот. Линкер - как раз "наоборот".

Что он делает ? Он читает группу файлов (чуть ли не до 30 штук можно), выдёргивает из них таблицы импорта и имён и затем начинает их тасовать.

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

Чтобы добится почти 100% универсальности, авторы линкера пошли наикрутейшим путём:

1) Все файлы читаются побайтно. Самое странное, что даже там, где нужно просто пропустить кусок, вместо того чтобы использовать POSITION (fseek), авторы пропускают байты вызовами RDBYTE (fgetc).

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

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

Я думаю, это тот случай, когда проще уже было бы написать всё на бейсике: массивы 16-битных там есть, логика программы была бы гораздо более очевидной.

А если сделать какую-то логику фрагментарного чтения (блок-за-обращение) - это бы уже легко компенсировало потери на работе интерпретатора. К сожалению, прочитать произвольный файл (а LINKER читает B, К, R/П-типы) по частям можно только накручивая над стандартными ДОСами свои надстройки, но оно бы того стоило.

Более того, если предположить, что файлы не такие уж здоровые (всё таки это уже не текст), то читая файл-за-обращение, можно было бы и логику не особо усложнять. Свободного ОЗУ в агате не мало, такой подход проиграл бы только в момент сборки какого-то огромного исполняемого файла, занимающего кб 40 (160 блоков).

Через это всё я предполагаю, что линкер не стал практически использоваться из-за крайней тормознутости. Я часто гоняю тестовый пример, состоящий из 4-х файлов, примерно по полблока (128 байт) каждый. Линкеру требуется где-то секунд 15 на их обработку (если не турбировать :). Что будет, если загнать в него несколько Кб кода и таблиц - не знаю. Но попробую.

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

Он состоит из 4-х частей: сперва идёт 6 байт заголовка, затем исполняемый код и две таблицы: RLD и STB.

1) Таблица реаллокации (RLD). Это список смещений в коде, в которых линкеру что-то нужно изменить.

2) Таблица имён (STB). Любые переменные, через которые код данного файла связан с другими П-файлами.

Как используются таблицы объясню на примерах:

 ORG $2800
 REL

ST
 JMP ST

ST - метка. Она не импортируется (так как объявлена в этом файле). Но в команде JMP она должна быть пересчитана, так как точка загрузки файла заранее неизвестна. В П-файл на её место будет записано число $2800, а адрес ($2801) этого места попадёт в таблицу RLD.
Если линкер разместит код из этого файла по адресу $1000, из таблицы RLD он узнает, что значение по адресу $2801 нужно пересчитать как СТАРОЕ_ЗНАЧЕНИЕ - СТАРЫЙ_ORG +  НОВЫЙ_ORG. В таблице STB об этом ничего не будет сказано, так как имя ST не экспортируется.

А вот если в текст будет добавлено "ENTRY ST", то в таблице STB появится запись о том, что существует такая переменная ST и её адрес $2800, но при этом будет стоять пометка, что адрес является перемещаемым и перед использованием в другом файле его сперва нужно пересчитать.

Если теперь команду JMP ST убрать из текста, это приведёт к удалению записи из таблицы RLD, в STB запись останется.

 ORG $2800
 REL

 EXTRN ST
 JMP ST

Здесь ST будет задано значение $0000. А таблицы будут заполнены так: в STB будет зарегистрировано имя ST с неизвестным адресом, а в RLD появится запись об адресе $2801, но будет стоять пометка, что адрес является импортируемым и ссылка на запись в таблице STB.

 ORG $2800
 REL

 EXTRN ST
 ENTRY ST

В этом примере получится пустой код, запись будет только в таблице STB о неизвестном имени ST, которое отмеченно - одновременно - как импортируемое и экспортируемое.

Это пока были обычные двухбайтовые указатели. Но можно сделать и однобайтовые:

 ORG $2800
 REL

 EXTRN ST
 DFB >ST

Получим запись в STB о неизвестном значении ST, а в RLD указатель $0000 со ссылкой на запись в STB, но с флажком, указывающим, что требуется только один младший байт.
Если DFB > заменить на DDB (сохранение значения в порядке старший-младший), оно будет сохранено также, но с отметкой о двух байтах, хранимых в прямом порядке.

 ORG $2800
 REL

ST:
 DFB <ST

Этот пример, хотя и выглядит почти как предыдущий, на самом деле сложнее. Дело в том, что
в RLD указывается, что по смещению $0000 нужно пересчитать значение и сохранить его старший байт. Но чтобы пересчитать правильно, нужно знать и младший байт этого значения (ST). И в этой ситуации он сохраняется в RLD.

Свои особенности начинаются, если переменная объявлена через EQU либо как метка внутри DSECT..DEND. В этом случае она может стать как статичной (независящей от реаллокаций кода), так и динамической (и я пока не понял, в каких случаях это происходит).

К сожалению, следующий пример, хотя и компилируется без ошибок, работает не так, как бы хотелось:

 ORG $2800
 REL

 EXTRN ST
AX EQU ST
 JMP ST

Запись в STB о переменной ST появится, в RLD тоже будет ссылка на аргумент команды JMP, но AX будет иметь значение 0 и в таблицы не попадёт.
Тоже происходит, если, например, ST будет использовано внутри DSECT..DEND как аргумент ORG. Компилятор воспримет это как ORG 0 и все переменные внутри DSECT получат фиксированные адреса начиная от 0.

Это плохо, хотя, в "больших" ассемблерах для решения такой проблемы есть понятие именованного сегмента: например, если вы объявляете в любых частях программы сегмент с именем DATA и объявляете переменные разных частей в нём, то на выходе, задав фактический адрес этого сегмента (например, $E0), вы разместите все переменные подряд от адреса $E0 и выше (по порядку их нахождения в частях программы).

Как видно, между всего -то двумя таблицами могут устанавливаться разные связи и нельзя выделить какую-то одну таблицу как более важную или ведущую. Как RLD так и STB могут иметь связанные записи, но могут иметь и самостоятельные. Более того, разные записи RLD могут ссылаться на одну и ту же запись в STB.

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

Всё это приводит к заметной сложности кода линкера.

Исправил найденные проблемы, линкер завёлся, в общем-то метки (входные точки) он вполне нормально понимает и обрабатывает.

Вылез мелкий косяк только:

 ORG $20
 REL

START:
 LDA START

Здесь ассемблер сделает LDA с ZP-адресацией и ему без разницы, что, возможно, я затем захочу собрать этот фрагмент на адресе $4000. Ну ладно. Не бага, в общем-то. Скорее, изъян архитектуры транслятор-линкер.

Но дальше полезло другое: любую метку можно объявить через EQU или DSECT. С точки зрения ассемблера, это уже как бы константы, а не метки. Разница в том, что "PI10000 EQU 31415" не должна допускать никакой настройки линкером - как константа, она не зависит от смены адресов. И тут линкер поплыл по полной: он вообще игнорирует флаг EQU, который ему ставит ассемблер. И пытается пересчитывать константы.

Ну это я исправил.

А вот дальше - ещё хуже. Во внутренних структурах линкера, там где собирается глобальная таблица переменных, есть такая дурацкая схема: если старший байт адреса = 0, то вроде как переменная не найдена. И её значение остаётся нулем или чем-то ещё. Ну она может быть не найдена, проблем нет, но ведь может встретится переменная, у которой реально старший байт адреса = 0. Чем думали разработчики - не знаю, но факт: VT EQU $28 не импортируется в прогу, хотя успешно присутствует в таблицах экспорта библиотеки.

Будем ковырять дальше.

(что-то сдаётся мне, что этот линкер немного не был доведён до ума, от того и забыт всеми)