Процесс линковки привязывает код и данные к памяти процессора (к абсолютным адресам его карты памяти). Для простой однопроцессорной архитектуры при линковке генерируется один файл .dxe. Одиночное вовлечение линкера в процесс привязки может создать несколько исполняемых файлов (.dxe) многопроцессорной (multiprocessor, MP) или многоядерной (multi-core, MC) архитектур. Линковка также может сгенерировать файл общей памяти (shared memory, .sm) для системы MP или MC. Большой исполняемый файл может быть поделен на меньший исполняемый файл и файл оверлея (overlay, .ovl), который содержит вызываемый при необходимости код (сбрасываемый во внутреннюю память процессора). Линкер выполняет эту задачу (здесь приведен перевод Главы 2 "Linker" руководства [1]).

Вы можете запустить линкер из командной строки или из интегрированной среды разработки и отладки (Integrated Development and Debugging Environment, IDDE) VisualDSP++.

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

Эта глава включает следующие секции:

• Работа линкера.
• Рабочее окружение линкера в операционной системе Windows.
• Сообщения об ошибках и предупреждения линкера.
• Линковка описания целевого процессора (Link Target Description).
• Справочник по командной строке линкера.

[Работа линкера]

Рис. 2-1 иллюстрирует базовую операцию линковки. Этот рисунок показывает несколько входных объектных файлов (.doj), которые связываются в один исполняемый (executable, .dxe) файл. Файл настроек линкера (linker description file, .ldf) управляет процессом линковки.

Рис. 2-1. Линковка объектных файлов в исполняемый файл.

Когда разрабатывается новый проект, используйте Project Wizard (для процессоров Blackfin) или Expert Linker (процессоры SHARC и TigerSHARC) для генерации файла LDF проекта. Для дополнительной информации см. Главу 4 "Expert Linker" или online help для "Project Wizard".

В многопроцессорной системе генерируется файл .dxe для каждого процессора. Например, для двухпроцессорной системы Вы должны генерировать два файла .dxe. Процессоры в многопроцессорной архитектуре могут иметь общую память (share memory). Когда это указано операторами файла .ldf, linker генерирует исполняемый файл shared memory (.sm), код которого используется несколькими процессорами.

Файлы оверлея, еще один вывод от линкера, поддерживают приложения, которые требуют больше инструкций программы и данных, чем может вместить внутренняя память. Для дополнительной информации см. раздел "Управление памятью с использованием оверлеев" ("Memory Management Using Overlays" из Главы 5 даташита [1]).

Подобно объектным файлам, исполняемые файлы делятся на выходные секции с уникальными именами. Выходные секции определены стандартным форматом файла Executable and Linking Format (ELF), которому удовлетворяет система разработки VisualDSP++.

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

Исполняемый файл (файлы) .dxe дополнительные файлы (.sm и .ovl) не загружаются в процессор, и не прошиваются в EPROM. Они используются для отладки приложения.

Управление работой линкера. Операции линкера направляются следующими опциями и командами:

• Ключи (опции) командной строки линкера. Подробнее см. раздел "Справочник по командной строке линкера".
• Рабочее окружение IDDE: настройки на страничке "Link" диалогового окна свойств проекта (Project Options). См. секцию "Сборки проекта".
• Команды LDF. Для получения подробного описания см. раздел "Команды LDF".

Опции линкера управляют тем, как линкер обработает объектные и библиотечные файлы. Эти опции указывают разные критерии, такие как директории поиска файлов, генерация выходного map-файла, удаление ненужного кода (dead code elimination).

Команды LDF в файле настроек линкера (linker description file, .ldf) определяют целевую карту памяти и размещение секций программы в памяти процессора. Текст этих команд дают информацию, необходимую для линковки Вашего кода.

Окно проекта VisualDSP++ отображает файл .ldf как файл исходного кода, хотя этот файл предоставляет входные команды для линкера.

С использованием директив в файле .ldf, линкер:

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

Правила процесса линковки. Процесс линковки соблюдает следующие правила:

• Каждый файл исходного кода (языка C/C++ или ассемблера) при компиляции генерирует один объектный файл.
• Файлы исходного кода могут задавать одну или большее количество входных секций в качестве места назначения для скомпилированных/ассемблированных объектов.
• Компилятор и ассемблер генерируют объектный код с метками (именами входных секций), которые могут использоваться для направления одной или большего количества порций объектного кода в определенные входные секции.
• В соответствии с указаниями файла .ldf линкер отображает (привязывает) каждую входную секцию в объектном коде на выходную секцию.
• В соответствии с указаниями файла .ldf линкер отображает (привязывает) каждую входную секцию на сегмент памяти процессора.
• Каждая входная секция может содержать несколько элементов кода, но каждый элемент кода может появляться только в одной входной секции.
• В выходную секцию может быть помешено больше одной входной секции.

Обзор файла LDF. Всякий раз, когда Вы линкуете функции C/C++ или подпрограммы ассемблера, используется одинаковый механизм. После преобразования файлов исходного кода в объектные файлы (это делает компилятор), линкер использует директивы в файле .ldf, чтобы комбинировать объекты в исполняемом (.dxe) файле, который может быть загружен в симулятор для тестирования.

Структура исполняемого файла удовлетворяет стандарту Executable and Linkable Format (ELF).

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

Когда разрабатывается новый проект, используется Project Wizard (процессор Blackfin) или Expert Linker (процессоры SHARC и TigerSHARC), чтобы сгенерировать файл LDF для проекта. Для дополнительной информации см. Главу 4 “Expert Linker” или выполните поиск в online help строки "Project Wizard".

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

За дополнительной информацией обратитесь к статье [6].

[Рабочее окружение линкера в операционной системе Windows]

Под этим имеется в виду окна приглашения командной строки Windows (cmd.exe) и среда разработки VisualDSP++ IDDE. При минимальном использовании через командную строку может быть запущена какая-нибудь из утилит разработки (как например линкер), и в той же командной строке (standard output) можно увидеть результат выполненной операции утилиты.

Интегрированная среда разработки VisualDSP++ предоставляет рабочее окружение, которое упрощает процесс сборки программного обеспечения для процессора. Из VisualDSP++ Вы указываете опции сборки в диалоге настроек проекта (Project Options), и модифицируете файлы проекта, включая linker description file (.ldf). Опция Type позволяет выбрать, что будет собрано - файл библиотеки (.dlb), исполняемый файл (.dxe), или файл образа (образ загрузки .ldr или другой). В выходном окне (окно Output) будут появляться сообщения об ошибках и предупреждениях.

Сборки проекта. Линкер запускается из командной строки операционной системы, инициированной из VisualDSP++ IDDE или окна командной строки, запущенной пользователем. Система VisualDSP++ IDDE предоставляет интуитивно-понятный интерфейс программирования для процессора. Когда Вы открываете VisualDSP++, её рабочая область содержит все необходимое для сборки проекта DSP, управления им и отладки кода. Вы можете просто создать или отредактировать файл .ldf, который отображает код или данные на определенные сегменты памяти целевого процессора (для которого предназначен проект приложения).

Для получения информации о рабочем окружении VisualDSP++ обратитесь к соответствующему руководству (VisualDSP++ User’s Guide) или online Help. Online Help предоставляет мощные возможности поиска. Чтобы получить информацию по элементу кода, параметру или ошибке выберите текст в окне редактора VisualDSP++ IDDE или окне Output, и нажмите на клавиатуре кнопку F1.

В среде VisualDSP++ укажите настройки инструментария для сборок проекта. Используйте меню Project, чтобы открыть диалог настроек проекта (окно Project Options). Страницы этого диалога позволят Вам выбрать целевой процессор, тип и имя выходного файла, а также инструменты VisualDSP++, доступные для использования с выбранным процессором.

Страничка Link диалога Project Options используется для выбора и/или установки функциональных опций линкера (рис. 2-2).

Рис. 2-2. Страничка Project Options –> Link, раздел General (общие настройки линковки).

На страничке настроек Link есть четыре раздела - General, LDF Preprocessing, Elimination и Processor. Рис. 2-2 показывает пример открытого раздела Project Options -> Link -> General. Большинство опций диалога соответствуют опциям командной строки компилятора, которые описаны в секции "Справочник по командной строке линкера".

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

Для разных процессорных архитектур могут быть доступны разные опции странички настроек Link. Используйте в VisualDSP++ контекстный online Help, чтобы получить информацию об элементах управления диалога опций проекта (в частности по опциям линкера). Для этого кликните на кнопку с символом "?", и затем кликните на нужное поле, галочку, выпадающий список или кнопку, по которым нужно получить информацию.

Expert Linker. Среда VisualDSP++ IDDE предоставляет интерактивный инструмент Expert Linker, чтобы отобразить код или данные на определенные сегменты памяти процессора. Когда разрабатывается новый проект, используйте Expert Linker для генерации LDF.

Окно Expert Linker графически отображает информацию .ldf - объектные файлы, макросы LDF, библиотеки и описание целевой памяти. В Expert Linker используйте операции "перетащить и бросить" (drag-and-drop), чтобы организовать объектные файлы в графическом представлении карты памяти. Когда Вы удовлетворили конфигурации памяти, генерируется исполняемый файл (.dxe).

Окно Expert Linker открывается двойным щелчком по файлу .ldf проекта, имя которого отображается в дереве файлов (папка Linker Files).

На рис. 2-3 показано окно Expert Linker, которое состоит из 2 панелей: Input Sections (входные секции) и Memory Map (выходные секции, карта памяти). За подробной информацией обратитесь к Главе 4 "Expert Linker".

Рис. 2-3. Окно Expert Linker.

[Сообщения об ошибках и предупреждения линкера]

Сообщения линкера записываются в окно Output среды VisualDSP++, или в standard output консоли операционной системы Windows (когда линкер запускается из командной строки). Сообщения описывают проблемы, с которыми столкнулся линкер при обработке файла .ldf. Предупреждения (Warnings) показывают ошибки обработки, которые недостаточно серьезные, чтобы не дать линкеру сгенерировать формально корректный выходной файл (как например сообщения о неиспользуемых символах в Вашем коде). Ошибки (Errors) будут выданы, когда линкер столкнулся с ситуацией, которая не дает ему возможности сгенерировать выходной файл.

Обычно эти сообщения включают имя файла .ldf, номер строки, к которой относится сообщение, 6-символьный код и краткое описание причины ошибки или предупреждения. Пример:

linker -proc ADSP-unknown a.doj [Error li1010] The processor 'ADSP-unknown' is
unknown or unsupported.

Вы можете получить описание сообщений линкера путем выбора шести символов кода сообщения (например li1010) и нажатия клавиши F1.

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

Некоторые ошибки сборки, такие как ссылка не определенный символ (undefined symbol), не коррелируют непосредственно с исходными файлами. Эти ошибки часто связаны с упущениями в файле .ldf. Например, если входная секция из объектного файла не размещена файлом .ldf, то произойдет ошибка перекрестной ссылки (cross-reference error) на каждом объекте, который относится к меткам, задающим размещение в отсутствующей секции. Исправьте эту проблему путем пересмотра файла .ldf и указания в нем всех секций, которые требуют размещения (как вариант, исправьте исходный код, чтобы задать в нем другие, существующие секции для размещения объектов кода). Для дополнительной информации обратитесь к online Help.

[Линковка описания целевого процессора (Link Target Description)]

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

• Физическая карта памяти.
• Размещение программы в карте памяти системы.

Если в проекте нет файла .ldf, то линкер использует файл .ldf по умолчанию для процессора, который соответствует опции -proc < processor > командной строки линкера (или выбранному процессору в выпадающем списке Processor, который находится в диалоге Project Options проекта VisualDSP++ IDDE).

Удостоверьтесь, что понимаете архитектуру памяти процессора, которая описана в соответствующем даташите на аппаратуру процессора (Hardware Reference) и его даташите.

Этот раздел содержит следующие секции:

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

Представление архитектуры памяти. Команда MEMORY{} файла .ldf используется для представления архитектуры памяти Вашей процессорной системы. Линкер использует эту информацию для размещения исполняемого файла в память системы.

Чтобы оформить команду MEMORY{}, рассмотрите следующие вопросы:

• Использование памяти - список вариантов, которыми Ваша программа использует память системы. Типичное использование сегментов памяти включает таблицы векторов прерываний, данные инициализации, код программы, данные, область кучи и область стека. Подробнее см. "Указание отображения на память".
• Характеристики памяти - список типов памяти в Вашей процессорной системе, диапазон их адресов и ширину слова для каждого типа памяти. Тип памяти определяется как RAM или ROM.
• Команда MEMORY{} - создайте (или проверьте) В файле .ldf команду MEMORY{}, чтобы скомбинировать информацию из предыдущих двух пунктов, и декларировать сегменты памяти Вашей системы.

Для полной информации см. описание команды MEMORY{} в [6].

[Указания линкеру для отображения на память]

Встраиваемое программное обеспечение должно удовлетворять ограничениям, которые накладывает ширина шины данных процессора и возможности его адресации. Следующую информацию описывает файл .ldf для некого гипотетического проекта. Этот файл задает несколько сегментов памяти, что поддерживается командой SECTIONS{}, как это показано в её описании (см. [6]).

При выделении памяти важны следующие вопросы:

• Использование памяти и сегменты памяти по умолчанию.
• Обзор характеристик памяти.
• Команда линкера MEMORY{} в LDF.

Использование памяти и сегменты памяти по умолчанию. Имена входных секций генерируются компилятором автоматически, или указываются в исходном коде ассемблера. Файл .ldf определяет имена сегментов памяти и имена выходных секций. По умолчанию файл .ldf обрабатывает все генерируемые компилятором входные секции (см. столбец "Входная секция" в таблицах 2-1, 2-2 и 2-3). Сгенерированный файл .dxe имеет соответствующую выходную секцию для каждой входной секции. Хотя программисты обычно не используют метки выходных секций, эти метки используются другими нижележащими инструментами.

Используйте утилиту ELF file dumper (elfdump.exe), чтобы получить дамп содержимого выходной секции (например, data1) исполняемого файла. Информацию по этой утилите см. в разделе "elfdump - ELF File Dumper".

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

За подробностями обратитесь к файлу .ldf по умолчанию для Вашего процессора и к руководству по аппаратуре для этого процессора (Hardware Reference). Также см. "Wildcard Characters".

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

int pm xyz[100];  // размещено в секции seg_pmda

int abc[100];     // размещено в seg_dmda

int dm def[100];  // размещено в seg_dmda

Обзор характеристик памяти. Эта секция дает базовую информацию о памяти (включая адреса и диапазоны адресов) для примеров целевых архитектур процессоров.

Некоторые порции памяти процессора зарезервированы. За дополнительной информацией обратитесь к аппаратному руководству процессора (Hardware Reference).

[Команда линкера MEMORY{} в файле LDF]

С использованием информации из секций этой статьи "Использование памяти и сегменты памяти по умолчанию" и "Обзор характеристик памяти", Вы можете командой MEMORY{} описать память целевого процессора любой архитектуры (листинги 2-1, 2-2 и 2-3 предоставляют примеры для определенных процессоров).

Листинг 2-1. Код команды MEMORY{} процессора ADSP-21161.

MEMORY
{
seg_rth        { TYPE(PM RAM) START(0x00040000) END(0x000400ff)
                 WIDTH(48) }
seg_init       { TYPE(PM RAM) START(0x00040100) END(0x000401ff)
                 WIDTH(48) }
seg_int_code   { TYPE(PM RAM) START(0x00040200) END(0x00040287)
                 WIDTH(48) }
seg_pmco       { TYPE(PM RAM) START(0x00040288) END(0x000419ff)
                 WIDTH(48) }
seg_pmda       { TYPE(PM RAM) START(0x00042700) END(0x00043fff)
                 WIDTH(32) }
seg_dmda       { TYPE(DM RAM) START(0x00050000) END(0x00051fff)
                 WIDTH(32) }
seg_heap       { TYPE(DM RAM) START(0x00052000) END(0x00052fff)
                 WIDTH(32) }
}

Листинг 2-2. Код команды MEMORY{} процессора ADSP-TS101.

/* Файл TS101_memory.ldf */
MEMORY
{/* Внутренние блоки памяти размером 0x10000 (64K байт) */
M0Code   {TYPE(RAM) START(0x00000000) END(0x0000FFFF) WIDTH(32)}
M1Data   {TYPE(RAM) START(0x00080000) END(0x0008BFFF) WIDTH(32)}
M1Stack  {TYPE(RAM) START(0x0008C000) END(0x0008FFFF) WIDTH(32)}
M2Data   {TYPE(RAM) START(0x00100000) END(0x0010BFFF) WIDTH(32)}
M2Heap   {TYPE(RAM) START(0x0010C000) END(0x0010C7FF) WIDTH(32)}
M2Stack  {TYPE(RAM) START(0x0010C800) END(0x0010FFFF) WIDTH(32)}
SDRAM    {TYPE(RAM) START(0x04000000) END(0x07FFFFFF) WIDTH(32)}
MS0      {TYPE(RAM) START(0x08000000) END(0x0BFFFFFF) WIDTH(32)}
MS1      {TYPE(RAM) START(0x0C000000) END(0x0FFFFFFF) WIDTH(32)}
}

Листинг 2-3. Код команды MEMORY{} процессора ADSP-BF533.

MEMORY /* Определение/метка системной памяти */
{ /* Список глобальных сегментов памяти */
   MEM_L2_CODE
      { TYPE(RAM) START(0xF0000000) END(0xF002FFFF) WIDTH(8) }
   MEM_L1_DATA_A
      { TYPE(RAM) START(0xFF800000) END(0xFF803FFF) WIDTH(8) }
   MEM_L1_DATA_B
      { TYPE(RAM) START(0xFF900000) END(0xFF903FFF) WIDTH(8) }
   MEM_HEAP
      { TYPE(RAM) START(0xF0030000) END(0xF0037FFF) WIDTH(8) }
   MEM_STACK
      { TYPE(RAM) START(0xF0038000) END(0xF003DFFF) WIDTH(8) }
   MEM_ARGV
      { TYPE(RAM) START(0xF003FE00) END(0xF003FFFF) WIDTH(8) }
   MEM_SDRAM0
      { TYPE(RAM) START(0x00000004) END(0x07FFFFFF) WIDTH(8) }
}

Приведенные выше примеры относятся к предыдущему обсуждению того, как писать команду MEMORY{}, и для последующего обсуждения команды SECTIONS{}. Команда SECTIONS{} не атомарна; она может быть сочетаться с другими директивами, включая информацию счетчика размещения (location counter). Вы можете определить новые символы внутри файла .ldf. Эти примеры определяют начальный адрес стека, самый большой возможный адрес стека, и также начальное место размещения кучи и её размер. Эти новые созданные символы вводятся в таблицу символов исполняемых файлов.

[Адрес элемента (Entry Address)]

В релизах до VisualDSP++ 4.5 адрес входа в программу заполнялся из глобального символа start (без нижнего подчеркивания), если он присутствовал. Символ "start" должен был быть глобальным символом или символом LDF.

В настоящее время поле адреса входа может быть установлено следующими способами:

• Опцией командной строки -entry, где аргументом опции является символ.
• Командой ENTRY(символ) в файле .ldf. Если присутствуют оба варианта, и -entry, и ENTRY(), то они должны быть одинаковые. Способы -entry и ENTRY() не переназначают установки друг друга: если они не совпадают, то линкер определит ошибку.
• Если опция командной строки -entry или команда ENTRY() отсутствуют, то используется значение глобального символа файла start, или символ LDF start, если они присутствуют.
• Если ни один из способов указания адреса не использован, то адрес входа равен 0.

Мультипроцессорные/многоядерные приложения. Опция командной строки -entry применена для multiprocessor/multi-core файла .ldf, то она накладывает одинаковый адрес элемента для всех процессоров. Если адреса элементов отличаются (в многопроцессорных системах), то используйте команды ENTRY() в файле .ldf, и не используйте опцию командной строки -entry.

Если опция командной строки -entry указана, то произойдет ошибка в случае, когда любой из процессоров использует команду ENTRY() с другой спецификацией.

Символы группового замещения (Wildcard Characters). Линкер поддерживает использование wildcards в спецификациях имени входной секции файла .ldf. Символы wildcard * and ?, предоставленные в имени входной секции, дают возможность указать несколько входных секций.

* соответствует любому количеству символов
? соответствует любому одному символу

Для получения информации по используемым символам wildcard (и примерам использования) см. описание команды INPUT_SECTIONS().

[Размещение кода в целевом процессоре]

Используйте команду SECTIONS{}, чтобы отобразить код и данные на физическую память процессора в системе, где он применяется. Чтобы написать команду SECTIONS{}, выполните следующее:

1. Перечислите все входные секции, определенные в файлах исходного кода.

• Для файлов на ассемблере - перечислите каждую директиву .SECTION, встречающуюся в коде ассемблера, идентифицирующую её тип памяти (PM или CODE, DM или DATA), и обратите внимание на места, когда размещение кода критично для его функционирования. Эти порции .SECTIONS включают таблицы векторов прерываний, буферы данных, и встроенного в кристалл кода или данных (см. "Указание двух буферов в разных сегментах памяти" для информации, специфической для процессоров TigerSHARC).
• Для файлов на C/C++ - компилятор генерирует секции с именем "program" или "code" для кода, и именами "data1" и "data2" для данных. Эти секции соответствуют Вашему исходному коду, когда Вы не указываете секцию памяти путем расширения определения объектов необязательным ключевым словом section() (или соответствующей директивой #pragma section).

2. Сравните список входных секций с сегментами памяти, указанными в команде MEMORY{}. Идентифицируйте сегмент памяти, куда должна быть размещена каждая область .SECTION.

3. Скомбинируйте информацию из этих двух списков, чтобы записать одну или больше команд SECTIONS{} в файле .ldf.

Команды SECTIONS{} должны появляться в контексте команды PROCESSOR{} или SHARED_MEMORY().

В листинге 2-4 представлена команда SECTIONS{}, которая будет работать с командой MEMORY{} из листинга 2-1.

Листинг 2-4. Команда SECTIONS{} в LDF процессора ADSP-21161.

SECTIONS
{
   /* Начало выходных секций */
   seg_rth { // Хедер run-time и таблица прерываний
      INPUT_SECTIONS( $OBJS(seg_rth) $LIBS(seg_rth))
   } >seg_rth
   seg_init { // Инициализация
      ldf_seginit_space = . ;
      INPUT_SECTIONS( $OBJS(seg_init) $LIBS(seg_init))
   } >seg_init
   seg_init_code { // Данные инициализации
      INPUT_SECTIONS( $OBJS(seg_init_code)
      $LIBS(seg_init_code))
   } >seg_init_code
   seg_pmco { // Код PM
      INPUT_SECTIONS( $OBJS(seg_pmco) $LIBS(seg_pmco))
   } >seg_pmco
   seg_pmda { // Данные PM
      INPUT_SECTIONS( $OBJS(seg_pmda) $LIBS(seg_pmda))
   } >seg_pmda
   .bss ZERO_INIT {
      INPUT_SECTIONS( $OBJS(.bss) $LIBS(.bss))
   } >seg_dmda
   seg_dmda { // Данные DM
      INPUT_SECTIONS( $OBJS(seg_dmda) $LIBS(seg_dmda))
   } >seg_dmda
   heap {
      // Выделение кучи для приложения
      ldf_heap_space = .;
      ldf_heap_length = MEMORY_SIZEOF(seg_heap);
      ldf_heap_end = ldf_heap_space + ldf_heap_length - 1;
   } > seg_heap;
} // Конец секций

Листинг 2-5 представляет команду SECTIONS{}, которая должна работать с командой MEMORY{} из листинга 2-2.

Листинг 2-5. Команда SECTIONS{} в LDF процессора ADSP-TS101.

SECTIONS
{  /* Список секций для процессора P0 */
   sec_rth {INPUT_SECTIONS ( $OBJECTS(rth))} > seg_rth
   sec_code {INPUT_SECTIONS ( $OBJECTS(code)} > seg_code
   sec_code2 {INPUT_SECTIONS ( $OBJECTS(y_input)} > seg_code
   sec_data1 {INPUT_SECTIONS ( $OBJECTS(data1))} > seg_data1
}

Листинг 2-6 представляет команду SECTIONS{}, которая должна работать с командой MEMORY{} из листинга 2-3.

Листинг 2-6. Команда SECTIONS{} в LDF процессора ADSP-BF535.

SECTIONS
{  /* Список секций для процессора P0 */
   L1_code
   {
      INPUT_SECTION_ALIGN(2)
      /* Выравнивание всех секций кода на границу 2 байта */
      INPUT_SECTIONS( $OBJECTS(program) $LIBRARIES(program))
      INPUT_SECTION_ALIGN(1)
      INPUT_SECTIONS( $OBJECTS(data1) $LIBRARIES(data1))
      INPUT_SECTION_ALIGN(1)
      INPUT_SECTIONS( $OBJECTS(constdata)
      $LIBRARIES(constdata))
      INPUT_SECTION_ALIGN(1)
      INPUT_SECTIONS( $OBJECTS(ctor) $LIBRARIES(ctor) )
   } >MEM_L2_CODE

   program
   {
      /* Выравнивание всех секций кода на границу 4 байта */
      INPUT_SECTION_ALIGN(4)
      INPUT_SECTIONS( $OBJECTS(program) $LIBRARIES(program))
      INPUT_SECTIONS( $OBJECTS(data1) $LIBRARIES(data1))
      INPUT_SECTIONS( $OBJECTS(cplb) $LIBRARIES(cplb))
      INPUT_SECTIONS( $OBJECTS(cplb_code)
      $LIBRARIES(cplb_code))
      INPUT_SECTIONS( $OBJECTS(cplb_data)
      $LIBRARIES(cplb_data))
      INPUT_SECTIONS( $OBJECTS(constdata)
      $LIBRARIES(constdata))
      INPUT_SECTIONS( $OBJECTS(voldata) $LIBRARIES(voldata))
   } >MEM_PROGRAM

   stack
   {
      ldf_stack_space = .;
      ldf_stack_end =
      ldf_stack_space + MEMORY_SIZEOF(MEM_STACK) - 4;
   } >MEM_STACK

   heap
   {  /* Выделение кучи для приложения */
      ldf_heap_space = .;
      ldf_heap_end =
      ldf_heap_space + MEMORY_SIZEOF(MEM_HEAP) - 1;
      ldf_heap_length = ldf_heap_end - ldf_heap_space;
   } >MEM_HEAP
   
   argv
   { /* Выделение пространства для argv для приложения */
      ldf_argv_space = .;
      ldf_argv_end =
      ldf_argv_space + MEMORY_SIZEOF(MEM_ARGV) - 1;
      ldf_argv_length =
      ldf_argv_end - ldf_argv_space;
   } >MEM_ARGV
} /* Конец SECTIONS */

Определение 2 буферов в разных сегментах памяти. На процессорах TigerSHARC линкер поддерживает оптимизированное размещение в памяти с помощью директивы ассемблера .SEPARATE_MEM_SEGMENTS.

• Директива ассемблера .SEPARATE_MEM_SEGMENTS (или директива компилятора #pragma separate_mem_segments) задает размещать 2 буфера так, чтобы каждый из них размещался в разных сегментах памяти. Пример:

.SECTION data1;
.VAR buf1;
.VAR buf2;
.EXTERN buf3;
.SEPARATE_MEM_SEGMENTS(buf1, buf2);
.SEPARATE_MEM_SEGMENTS(buf1, buf3);

• Набор доступных сегментов памяти для каждого буфера определяется с использованием функции отображения линкера "one-to-many" (один ко многим) для входной секции (секций) чтобы разместить буферы в нескольких сегментах памяти. Пример:

data2 {
   INPUT_SECTIONS( $OBJECTS(data1) )
} >M2DataA 

data4 {
   INPUT_SECTIONS( $OBJECTS(data1) )
} >M4DataA

• Линкер пытается удовлетворить ограничение по размещению путем выделения буферов в разных сегментах памяти.

1. Если линкер не сможет удовлетворить условия размещения, то он выдаст предупреждение.
2. Все символы, которые упомянуты в .SEPARATE_MEM_SEGMENTS, будут отображены линкером самыми первыми до всего остального (за исключением абсолютного размещения).
3. Ссылка на символ в .SEPARATE_MEM_SEGMENTS является слабой ссылкой. Если такой символ определен в библиотеке, то линкер не берет этот символ из библиотеки (кроме случая, когда на этот символ есть прямая или косвенная ссылка из объектного файла).
4. Линкер игнорирует случаи, где символ, упомянутый в директиве ассемблера .SEPARATE_MEM_SEGMENTS, не определен, или не определен во входной секции (например, как символ LDF).

Для дополнительной информации см. раздел с описанием директив #pragma в Главе 1 руководства "VisualDSP++ 5.0 C/C++ Compiler and Library Manual for TigerSHARC Processors".

Линковка с атрибутами (обзор). В файле .ldf атрибуты используются для создания виртуальных подмножеств из обычных входных источников. Атрибуты связаны с файлами .doj, включая код, находящийся в библиотеке. Будучи созданными, эти подмножества существуют во время линковки и могут использоваться в любом месте библиотеки или списке объектов, нормально появляющемся в файле .ldf.

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

Атрибут это пара строк имя/значение. Допустимым именем атрибута является допустимый идентификатор языка C.

Имена атрибутов и значения атрибутов чувствительных к регистру (case-sensitive). Имена файлов Windows могут могут использоваться как значения, если позаботиться о непротиворечивости таких атрибутов.

Атрибут связывается с объектом (.doj), но не с библиотекой (.dlb), не с именем символа, и не с именем секции ELF. Объект имеет ноль или большее количество связанных с ним атрибутов. Имеющийся объект может иметь больше одного связанного с ним атрибута с таким же именем.

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

Линкер читает файл .ldf и использует команды фильтра {...} (например команды INPUT_SECTIONS), чтобы удалить из рассмотрения некоторые входные объекты перед разрешением символов. Линкер не меняет свое поведение, если в файле .ldf нет команд фильтра.

Поддержка оптимизации по информации профайлера (Profile-Guided Optimization, PGO). Архитектуры SHARC, TigerSHARC и Blackfin поддерживают специальный вид оптимизации, PGO. Это процесс сбора информации о работающем приложении путем запуска приложения с разными входными данными, и после этого выполнение повторной оптимизации с учетом собранной информации.

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

Файлы .ldf и VisualDSP++ IDDE работают совместно для предоставления аргументов командной строки. При нормальных условиях работы типичная embedded-программа не интересуется аргументами командной строки, и ничего подобного не получает. В этих нормальных ситуациях заголовок run-time привлекает функцию для обработки глобальной строки __argv_string[] и обнаруживает, что она пустая.

Для поддержки PGO может использоваться LDF-опция IDDE_ARGS для определения сегмента памяти с именем MEM_ARGV, и __argv_string[] непосредственно отображается на начало этой секции. Система VisualDSP++ IDDE следует соглашению, что аргументы командной строки могут могут быть переданы в приложение путем записи строки аргумента в память, указанную началом MEM_ARGV.

Для дополнительной информации о PGO см. руководство "VisualDSP++ 5.0 C/C++ Compiler and Library Manual" для подходящей архитектуры процессора.

Передача аргументов для симуляции и эмуляции. Символ _argv_string это строка, заканчивающаяся нулем (ASCIIZ, null-terminated string), и если она содержит что-либо кроме null, то это содержимое будет разделено каждым символом пробела, и результат помещен в массив argv[], который передается в функцию main при запуске системы (startup).

[Справочник по командной строке линкера]

В этой секции документации предоставлена следующая справочная информация:

• "Синтаксис командной строки линкера".
• "Опции командной строки линкера".

Когда Вы используете линкер в среде VisualDSP++ IDDE, настройки раздела Link диалога свойств проекта (Project Options) соответствуют опциям командной строки линкера. Здесь предоставлено подробное описание опций командной строки линкера и её синтаксис. Для дополнительной информации см. онлайн Help среды VisualDSP++.

Синтаксис командной строки линкера. Запуск линкера осуществляется следующими нормализованными форматами командной строки.

linker -proc processor -switch [-switch ...] object [object ...]
linker -T target.ldf -switch [-switch ...] object [object ...]

Команда линкера требует обработки опции -proc тип_процессора или -T < имя_файла_ldf >. Если в командной строке нет опции -proc тип_процессора, то файл .ldf, указанный опцией -T, должен содержать команду -ARCHITECTURE. Командная строка линкера может содержать обе эти опции, но команда ARCHITECTURE() файла .ldf должна соответствовать опции -proc тип_процессора.

Используйте опцию -proc тип_процессора вместо устаревшей опции командной строки -Darchitecture, чтобы выбрать целевой процессор. См. таблицу 2-7 для дополнительной информации.

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

Ниже приведено несколько примеров команд линкера.

linker -proc ADSP-21161 p0.doj -T target.ldf -t -o program.dxe
linker -proc ADSP-TS201 p0.doj -T target.ldf -t -o program.dxe
linker -proc ADSP-BF535 p0.doj -T target.ldf -t -o program.dxe

Командная строка линкера (кроме имен файлов) чувствительна к регистру символов (case sensitive). Например, действие опции -t отличается от опции -T.

Линкер может управляться компилятором через опцию командной строки -flags-link, которая явно передает опции линкеру. Для дополнительной информации см. Главу 1 руководства "VisualDSP++ 5.0 C/C++ Compiler and Library Manual" для подходящего процессора.

Когда используется командная строка линкера, изучите следующие темы:

• Объектные файлы командной строки.
• Имена файлов командной строки.
• Типы объектных файлов.

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

• Стандартные объектные файлы (.doj), производимые ассемблером.
• Один или большее количество библиотек (архивов), каждая с расширением .dlb. Примеры включают библиотеки C run-time и библиотеки математики, поставляемые вместе с VisualDSP++. Вы можете создать библиотеки общих или специализированных объектов. Специальные библиотеки доступны из алгоритмов DSP вендоров. Для дополнительной информации см. Главу 6 "Archiver" в руководстве [1].
• Исполняемый файл (.dxe), который является результатом линковки. Обратитесь к описанию $COMMAND_LINE_LINK_AGAINST в разделе "Встроенные макросы LDF".

Имена объектных файлов. Имя объектного файла может включать:

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

Если файл существует перед началом линковки, то линкер открывает этот файл, чтобы проверить его тип перед обработкой. Таблица 2-6 перечисляет допустимые расширения файла, используемые линкером.

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

Таблица 2-6. Соглашение о расширениях файла.

Линкер поддерживает относительные и абсолютные имена директорий, директории по умолчанию и выбранные пользователем директории для поиска файлов. Поиск файлов осуществляется в следующем порядке:

1. Указанный путь – если командная строка включает информацию об относительных или абсолютных путях, то линкер в этом месте ищет места размещения файлов.
2. Указанные директории – если Вы не включили информацию пути в командной строке, и файл не находится в директории по умолчанию, линкер ищет файл в директориях поиска, указанных опцией командной строки -L (path), и тогда директории поиска указываются командами SEARCH_DIR в файле .ldf. Директории перебираются при поиске в том порядке, в каком они появляются в командной строки или в файле .ldf.
3. Директория по умолчанию – если Вы не включили информацию пути в файле .ldf, указанном опцией командной строки -T, линкер ищет файл .ldf в текущей рабочей директории. Если Вы используете файл .ldf по умолчанию (опуская информацию LDF в командной строке, и указав вместо этого опцию -proc < тип_процессора >), то линкер ищет LDF в директории, специфичной для указанного процессора; например, в папке $ADI_DSP/Blackfin/ldf (здесь $ADI_DSP это каталог установки VisualDSP++).

Для дополнительной информации о путях поиска файлов, см. "Встроенные макросы LDF".

Когда в качестве параметров командой строки предоставляются имена входных и выходных файлов:

• Используйте пробел для разделения имен файлов в списке входных файлов.
• Заключите в прямые кавычки имена файлов, которые содержат пробелы; например, "long file name".
• Используйте подходящее расширение для каждого файла. Перед запуском обработки линкер открывает существующие файлы и проверяет их тип. Когда линкер создает файл, он использует расширение файла, чтобы определить тип создаваемого файла.

Типы объектных файлов. Линкер обрабатывает объект (файл) по типу файла. Тип файла определяется по следующим правилам:

• Существующие файлы открываются и анализируется, чтобы определить их тип. Имена файлов могут быть любыми.
• Файлы, созданные во время линковки, получает имена с подходящим расширением, и форматируются соответствующим образом. Выходной файл с информацией отображения (map-файл) генерируется только в формате XML, и получает расширение .xml. Исполняемый файл записывается в формате ELF и получает расширение .dxe.

Линкер обрабатывает объектные (.doj) файлы и библиотечные (.dlb) файлы, которые появляются в командной строке как объектные файлы для линковки. Линкер рассматривает исполняемые файлы (.dxe) и файлы общей памяти (shared memory, с расширением .sm) в командной строке как результат процесса линковки.

Для дополнительной информации об объектах см. описание макроса $COMMAND_LINE_OBJECTS. Для информации по исполняемым файлам см. описание макроса $COMMAND_LINE_LINK_AGAINST. Оба описаны в разделе документации "Встроенные макросы LDF".

Если объекты линковки не указаны в командной строке или в файле .ldf, то линкер генерирует информационные сообщения или сообщения об ошибке.

[Опции командной строки линкера]

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

Линкер предоставляет ключи (опции) для выбора операций и режимов. Стандартный синтаксис ключа: -ключ [аргумент_ключа].

Правила:

• Ключи могут использоваться в командной строке в любом порядке. Элементы в квадратных скобках [ ] являются необязательными. Элементы с наклонным текстом определяются пользователем, и описаны для каждого ключа.
• Имена путей могут быть отностельными или абсолютными.
• Имена файлов, содержащие пробелы или двоеточия (?..) должны быть заключены в двойные кавычки, хотя такие относительные пути, как ../../test.dxe, не требуют для себя кавычек.

Разные ключи требуют (или запрещают) пробелы между ключом и его параметром.

Пример:

linker -proc ADSP-BF535 p0.doj p1.doj p2.doj -T target.ldf -t -o program.dxe

Обратите внимание на разницу между ключами -T и -t. Этот пример вызова линкера имеет следующие ключи (опции) командной строки:

-proc ADSP-BF535
Указывает процессор.

p0.doj, p1.doj и p2.doj
Линкует между собой 3 объектных файла в исполняемый файл.

-T target.ldf
Использует вторичный файл LDF, чтобы указать размещение объектов в исполняемой программе.

-t
Включает информацию трассировки, что в виде эха выводит имя объекта в stdout по мере его обработки.

-o program.dxe
Указывает выходное имя линкуемого выполняемого файла.

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

Общее описание опций линкера. Таблица 2-7 кратко описывает каждый ключ линкера. Каждый отдельный ключ описан подробно после этой таблицы. См. "Сборки проекта" для получения информации по диалогу настройки опций проекта (Project Options) среды VisualDSP++.

Таблица 2-7. Общее описание ключей командной строки линкера.

Примечание: в столбце "Ключ (опция)" значение параметра (аргумента) опции указано наклонным шрифтом.

Следующие секции предоставляют подробное описание ключей (опций) командной строки линкера.

@filename
Ключ @ указывает линкеру рассматривать содержимое файла с именем filename в качестве входного для командной строки линкера. Ключ @ позволяет обойти ограничение на длину командной строки, накладываемое рабочим окружением Windows. Содержимое файла filename может не начинаться с имени программы "linker" (таким образом это не может быть полной строкой запуска линкера). Пробел (включая перевод на новую строку "newline") служит для разделения элементов командной строки (ключей/опций).

-Dprocessor
Ключ -Dprocessor (указание типа процессора) задает целевой процессор (архитектуру); например, -DADSP-BF533.

Ключ -proc processor (см. далее) является предпочтительной опцией для замены -Dprocessor.

В опции -D не разрешены пробелы до типа процессора processor. Параметр архитектуры чувствителен к регистру, и должен быть доступен в инсталляции VisualDSP++. Этот ключ (или ключ -proc processor) должен использоваться, если в командной строке не указан файл .ldf (см. описание опции -T). Этот ключ (или ключ -proc processor) должен использоваться, если указанный файл .ldf не имеет в себе команду ARCHITECTURE(). Противоречие в архитектуре между этим ключом командной строки и файлом .ldf приведет к ошибке.

-L path
Ключ -L path (директория поиска) добавляет имя пути для поиска библиотек и объектов. Этот ключ чувствителен к регистру символов, и использование пробелов является важным. Параметр path разрешает поиск любого файла, включая сам файл .ldf.

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

Пути, указанные в этой опции, используются для поиска перед путями, указанными в команде SEARCH_DIR{} файла LDF.

-M
Ключ -M (только генерация правил make) указывает линкеру проверить зависимости (dependency) и вывести результат в stdout.

-MM
Ключ -MM (генерация правил make и сборка) указывает линкеру генерировать выходной файл, который подойдет утилите make, описывающий зависимости (dependencies) исходного файла. Линкер проверяет зависимость, выводит результат в stdout, и выполняет сборку. Различие в действии между -MM и -M только в том, что с опцией -MM продолжается линковка. Для дополнительной информации см. описание ключа -M.

-Map filename
Ключ -Map filename (генерация карты памяти отображения объектов, memory map) указывает линкеру вывести карту памяти всех размещенных символов программы. Имя map-файла соответствует аргументу filename. Линкер генерирует map-файл только в формате XML. Например, если аргумент имени файла test, то имя выходного файла будет test.map.xml.

Открытие файла .xml в веб-браузере предоставляет организованный вид на map-файл (подробнее про просмотр map-файла см. [4]). С помощью гиперссылок в этом открытом файле можно быстро найти соответствующую информацию. Поскольку формат файлов .xml может быть расширен между релизами VisualDSP++, то map-файл зависит от частной инсталляции VisualDSP++ (хотя компания Analog Devices на момент написания статьи больше не продвигает VisualDSP++, заменив её на среду разработки CrossCore Embedded Studio). Таким образом, map-файл в формате .xml может использоваться только на том компьютере, на котором он был сгенерирован. Чтобы просмотреть map-файл на другом компьютере, он должен быть преобразован в формат HTML с помощью утилитой командной строки xmlmap2html.exe. Эта утилита делает возможность просмотра карты памяти (map-файла) виртуально на любом компьютере в любом браузере.

XSLT это язык для трансформации документов XML. Система VisualDSP++ включает в себя следующие XSLT-файлы для трансформации и отображения в браузере map-файлов XML, сгенерированных линкером.

• System/linker_map_ss1.xsl
Не отображает символы, которые начинаются с точки. Этот файл используется по умолчанию.

• /System/linker_map_ss2.xsl
Приводит к отображению всех символов.

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

-MDmacro[=def]
Ключ -MDmacro[=def] (определение макроса) декларирует и назначает значение def в качестве подстановки macro в качестве макроса препроцессора. Например, -MDTEST=BAR обработает код за директивой #ifdef TEST==BAR в файле LDF (и соответственно не будет обработан код за директивой #ifdef TEST==XXX).

Если =def не указан, этот макрос декларируется и устанавливается в "1", чтобы гарантировать, что будет обработан код после #ifdef TEST. Этот ключ может повторяться в командной строке несколько раз.

-MUDmacro
Ключ -MUDmacro (отмена определения макроса macro) удаляет макрос препроцессора, где macro задает удаляемый макрос. Например, -MUDTEST отменяет определение макроса TEST. Этот ключ обрабатывается после обработки всех ключей -MDmacro. Ключ -MUDmacro может быть повторен в командной строке несколько раз.

-S
Ключ -S (strip debug symbol) указывает линкеру опускать отладочную информацию исходного кода из выходного файла. Сравните этот ключ с ключом -s.

-T filename
Ключ -T filename (файл команд линкера) указывает линкеру использовать filename в качестве имени файла .ldf. Файл .ldf, указанный за ключом -T, должен содержать в себе команду ARCHITECTURE(), если командная строка не содержит ключ -proc < processor >. Линкер требует ключ -T, когда код линкуется для процессора, поддержка которого не предоставляется инсталляцией VisualDSP++. В таких случаях процессор идентификатор процессора (processor ID) не появляется в поле Target processor диалога опций проекта (Project Options).

Файл с именем filename должен существовать и быть найденным (например, путь до него указан с помощью опции -L). Перед filename должен быть пробел. На имя файла не вводятся ограничения, т. е. оно может быть любым, но допустимым для файловой системы, и содержимое файла правильное. Например, имя a.b работает, если это нормальный файл .ldf, где .ldf является допустимым расширением для такого файла, но оно не требуется.

-Werror [number]
Ключ -Werror указывает линкеру считать указанное предупреждающее (warning) сообщение ошибкой. Аргумент number задает номер обрабатываемого сообщения.

-Wwarn [number]
Ключ -Wwarn указывает линкеру обрабатывать сообщение об ошибке как предупреждающее сообщение (warning). Аргумент number задает номер обрабатываемого сообщения.

-Wnumber[,number]
Ключ -Wnumber или -wnumber (подавление предупреждения, warning suppression) селективно запрещает выдачу указанных предупреждающих сообщений по одному или большему количеству номеров. Например, -W1010 запрещает сообщение li1010. Опционально этот ключ принимает список сообщений следующим образом: [,number ...].

-e
Ключ -e указывает линкеру удалить не используемые символы из исполняемого файла.

-ek sectionName
Ключ -ek sectionName (нет удаления elimination) указывает секцию, к которой не применяется алгоритм устранения не используемых символов. Этот ключ и LDF-команда KEEP_SECTIONS() могут использоваться для указания имени секции, в которой не будет работать функция elimination.

-es sectionName
Ключ -es sectionName (удаление в перечисленной секции) указывает секцию, к которой применяется алгоритм elimination (удаления не используемых символов). Этот ключ ограничивает elimination только на перечисленные секции. Ключ -es может использоваться в командной строке несколько раз. При отсутствии ключа -es или команды ELIMINATE_SECTIONS() в файле LDF, линкер применяет elimination ко всем секциям. Оба этих ключа и LDF-команда ELIMINATE_SECTIONS() могут использоваться для указания секций, из которых будет удалены (eliminated) не используемый код и неиспользуемые данные.

Чтобы правильно работали библиотеки C/C++ run-time, должны быть сохранены следующие символы с помощью команды KEEP() файла LDF: ___ctor_NULL_marker и ___lib_end_of_heap_descriptions.

-entry
Ключ -entry показывает адрес элемента (entry address), где аргумент может быть либо символом, либо адресом.

-ev
Ключ -ev указывает линкеру удалять (eliminate) не используемые символы и сообщать о каждом удаленном символе.

-flags-meminit -opt1[,-opt2...]
Ключ -flags-meminit передает список опций, разделенных запятыми, в утилиту инициализатора памяти (Memory Initializer; для дополнительной информации см. Главу 7 "Memory Initializer" руководства [1]).

-flags-pp-opt1[,-opt2...]
Ключ -flags-pp передает каждую опцию из списка (с разделителем-запятой) в препроцессор.

Используйте -flags-pp с осторожностью. Например, если разрешен стандартный синтаксис комментария pp (pp legacy comment syntax), то символы комментария станут недоступными для синтаксиса не комментария.

-h[elp]
Ключ -h или -help указывает ассемблеру вывести в stdout список ключей (опций) командной строки с общим описанием синтаксиса.

-i|I directory
Ключ -idirectory или -Idirectory (подключить директорию, include directory) указывает линкеру добавить указанную директорию к путям поиска для подключаемых файлов.

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

-ip
Ключ -ip (индивидуальное размещение, individual placement) указывает линкеру заполнить фрагментированную память индивидуальными объектами данных, которые там поместятся. Когда указан ключ -ip в командной строке линкера (или с помощью диалога опций проекта VisualDSP++ IDDE), переназначается поведение по умолчанию линкера для размещения блоков данных в идущих друг за другом адресах. Ключ -ip позволяет индивидуальное размещение группирования данных в памяти процессора, чтобы позволить более эффективную упаковку данных.

Абсолютное размещение имеет приоритет перед размещением секции данных/программы в следующих друг за другом ячейках памяти. Когда оставшаяся часть памяти недостаточна для размещения всей секции, линковка терпит неудачу. Ключ -ip позволяет линкеру распаковать блок данных для индивидуального размещения и заполнения фрагментированных областей памяти.

-jcs2l
Ключ -jcs2l (jump/call от короткого short к длинному long) указывает линкеру преобразовать не достающие по диапазону адреса инструкции вызова функций (call) и инструкции перехода (jump) в последовательность кода, который использует косвенные (indirect) переходы или вызовы. Из-за того, что косвенная последовательность использует регистр P1, расширение будет применено только к инструкциям, использующим коды операций CALL.X или JUMP.X.

Ключ -jcs2l используется только для процессоров Blackfin.

Следующая таблица показывает, как линкер Blackfin обрабатывает преобразования jump/call.

Обратитесь к руководству по системе команд целевой архитектуры (для процессора Blackfin см. [5]) для получения дополнительной информации по инструкциям перехода и вызова.

-jcs2l+
Устаревший эквивалент ключа -jcs2l.

Ключ -jcs2l+ используется только для процессоров Blackfin.

-keep symbolName
Ключ -keep symbolName (сохранение неиспользуемых символов) указывает линкеру сохранить символ, который иначе был бы уничтожен (eliminated). Это указывает линкеру (когда разрешены -e или -ev) сохранить перечисленные символы в исполняемом файле, даже если они не используется в программе (если на них нет ссылок).

-meminit
Ключ -meminit (завершающая обработка исполняемого файла) указывает линкеру выполнить post-process файла .dxe с помощью утилиты Memory Initializer (для дополнительной информации см. Главу 7 "Memory Initializer" руководства [1]). Это действие приводит к тому, что секции, указанные в файле .ldf, будут инициализированы во время выполнения кода (run-time) с помощью библиотеки C run-time. По умолчанию, если это флаг не указан, все секции инициализируются в момент загрузки кода (load time; например, через отладчик VisualDSP++ IDDE или через boot loader процессора). Подробнее см. описание команды SECTIONS{} для получения информации по инициализации секции. Для информации о предопределенном макросе __MEMINIT см. описание __MEMINIT__.

-nomemcheck
Ключ -nomemcheck (memory checking off) позволяет Вам выключить проверку памяти.

-o filename
Ключ -o filename (выходной файл) устанавливает значение макроса $COMMAND_LINE_OUTPUT_FILE, который обычно используется как параметр LDF-команды OUTPUT(), которая задает имя выходного файла. Если в командной строке нет ключа -o, то макрос $COMMAND_LINE_OUTPUT_FILE получит значение "a.dxe".

-od directory
Ключ -od указывает линкеру присвоить значение LDF-макросу $COMMAND_LINE_OUTPUT_DIRECTORY. Этот ключ позволяет Вам сделать изменение командной строки, которое распространится на многие места без изменения LDF. Подробнее см. "Встроенные макросы LDF" [6].

-pp
Ключ -pp (завершить после обработки препроцессором, end after preprocessing) указывает линкеру остановиться после прохода препроцессора, завершить после этого работу без ликовки. Результат (обработанный препроцессором LDF) напечатается в файл с тем же именем, что и .ldf, но с расширением .is. Этот файл находится в той же директории, что и файл .ldf.

-proc processor
Ключ -proc (целевой процессор, target processor) указывает линкеру генерировать код, подходящий для указанного типа процессора. Пример:

linker -proc ADSP-BF533 p0.doj p1.doj p2.doj -o program.dxe

См. также описание опции -si-revision version для дополнительной информации о том, как указать ревизию кремния (silicon revision) требуемого процессора.

-reserve-null
Ключ -reserve-null указывает линкеру зарезервировать в памяти 4 адресуемых ячейки (words) по адресу 0x0. Это полезно для программ C/C++, чтобы избежать размещения кода или данных по адресу нулевого указателя (NULL pointer).

-s
Ключ -s (strip all symbols) указывает линкеру опустить из выходного файла все символьную информацию.

Некоторая функциональность отладчика (включая "run to main"), все функции stdio, и возможность остановки по окончании выполнения программы полагаются на способность отладчика найти определенные символы в исполняемом файле. Этот ключ удалит такие символы.

-save-temps
Ключ -save-temps указывает линкеру сохранить временные (промежуточные) выходные файлы.

-si-revision version
Ключ -si-revision version (версия кристалла процессора) указывает линкеру собрать программу с учетом определенной ревизии аппаратуры кристалла. Когда учет целевой ревизии разрешен, это позволяет применить способы обхода ошибок (errata workarounds), обнаруженных в определенной версии кристалла. Параметр версии представляет ревизию силикона процессора, который указан ключом -proc. Пример:

linker -proc ADSP-BF533 -si-revision 0.1

Если используется версия силикона "none", то в коде не разрешено применение обхода ошибок. Если указать версию силикона "any", то это разрешает применение всех errata workarounds для целевого процессора.

Если ключ -si-revision не используется, то линкер делает сборку для самой последней silicon revision силикона целевого процессора, при этом разрешены все errata workarounds для последней silicon revision.

Если silicon revision установлена в "any", то макрос __SILICON_REVISION__ устанавливается в значение 0xffff. Если ключ -si-revision установлен в "none", то линкер не будет устанавливать макрос __SILICON_REVISION__.

Линкер передает ключ -si-revision < silicon version >, когда запускается другой инструментарий VisualDSP++, например когда линкер привлекает работу ассемблера. В примере ниже линкер Blackfin:

linker -proc ADSP-BF533 -si-revision 0.1

... запустит ассемблер командой:

easmblkfn -proc ADSP-BF533 -si-revision 0.1

-sp
Ключ -sp (пропуск обработки препроцессором) указывает линкеру связывать код без предварительной обработки файла .ldf.

-t
Ключ -t (trace, трассировка) указывает линкеру вывести имена объектов линковки в стандартный вывод по мере их обработки.

-tx
Ключ -tx (full trace, полная трассировка) указывает линкеру выводить полные имена объектов линковки (полный путь файла с директорией) в стандартный вывод по мере их обработки.

-v[erbose]
Ключ -v или -verbose (verbose, подробно) указывает линкеру отобразить версию и информацию командной строки для каждой фазы линковки.

-version
Ключ -version (показать версию) указывает линкеру вывести информацию о его версии.

-warnonce
Ключ -warnonce (single symbol warning, предупреждение одного символа) указывает линкеру предупредить только один раз о каждом не определенном символе, вместо того, чтобы сообщать о каждой ссылке на этот символ.

-xref
Ключ -xref указывает линкеру сгенерировать файл перекрестных ссылок в формате XML (cross-reference file xref.xml) в выходной директории линкера. Файл XML может быть открыт для просмотра браузером (или программами для просмотра XML, см. [4]).

Этот ключ линкера отличается от ключа -xref драйвера компилятора.

[Ссылки]

1. VisualDSP++ 5.0 Linker and Utilities Manual site:analog.com.
2. PGO Linker: инструмент размещения кода для процессоров Blackfin.
3. Оптимизация системы на процессоре Blackfin.
4. Q070. VisualDSP: как посмотреть MAP-файл линкера?
5. Blackfin: система команд (ассемблер) - часть 1.
6. Linker Description File.