Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
Формат исполняемого файла
Executable file format
Общий объектный формат (COFF) — это формат для исполняемых файлов, объектного кода и общих библиотек, используемых в системах Unix. Он был представлен в Unix System V, заменил ранее использовавшийся формат a.out и послужил основой для расширенных спецификаций, таких как XCOFF и ECOFF, прежде чем был в значительной степени вытеснен ELF, представленным с SVR4. COFF и его варианты продолжают использоваться в некоторых Unix-подобных системах, в Microsoft Windows (Portable Executable), в средах UEFI и в некоторых системах встраиваемой разработки.
The Common Object File Format (COFF) is a format for executable, object code, and shared library computer files used on Unix systems. It was introduced in Unix System V, replaced the previously used a. out format, and formed the basis for extended specifications such as XCOFF and ECOFF, before being largely replaced by ELF, introduced with SVR4. COFF and its variants continue to be used on some Unix like systems, on Microsoft Windows (Portable Executable), in UEFI environments and in some embedded development systems.
История
Оригинальный формат файла объектов Unix a.out не способен адекватно поддерживать общие библиотеки, идентификацию файлов других форматов или явную привязку адресов. По мере развития Unix-подобных систем как внутри AT&T, так и за её пределами, возникали различные решения этих и других проблем. COFF был представлен в 1983 году в UNIX System V от AT&T для 32-битных платформ, отличных от VAX, таких как 3B20. Улучшения по сравнению с существующим форматом a.out от AT&T включали произвольные секции, явные объявления процессора и явную привязку адресов. Однако, конструкция COFF была одновременно слишком ограниченной и не полностью специфицированной: существовало ограничение на максимальное количество секций, на длину имён секций и включенных исходных файлов, а символическая отладочная информация не могла поддерживать реальные языки программирования, такие как C, не говоря уже о более новых языках, таких как C++, или новых процессорах. В результате все реальные реализации COFF неизбежно нарушали стандарт. Это привело к многочисленным расширениям COFF. IBM использовала формат XCOFF в AIX; DEC, SGI и другие – ECOFF; а множество портов SysV и цепочек инструментов, предназначенных для встраиваемых систем, создавали собственные, несовместимые варианты. С выпуском SVR4 компания AT&T заменила COFF на ELF. Хотя расширенные версии COFF продолжают использоваться для некоторых Unix и Unix-подобных платформ, в основном во встраиваемых системах, возможно, наиболее широкое распространение формат COFF получил сегодня в формате Portable Executable (PE) от Microsoft. Разработанный для Windows NT, формат PE (иногда записывается как PE/COFF) использует заголовок COFF для объектных файлов и как компонент заголовка PE для исполняемых файлов.
The original Unix object file format a. out is unable to adequately support shared libraries, foreign format identification, or explicit address linkage. As development of Unix like systems continued both inside and outside AT&T, different solutions to these and other issues emerged. COFF was introduced in 1983, in AT&T's UNIX System V for non VAX 32 bit platforms such as the 3B20. Improvements over the existing AT&T a. out format included arbitrary sections, explicit processor declarations, and explicit address linkage. However, the COFF design was both too limited and incompletely specified: there was a limit on the maximum number of sections, a limit on the length of section names, included source files, and the symbolic debugging information was incapable of supporting real world languages such as C, much less newer languages like C++, or new processors. All real world implementations of COFF were necessarily violations of the standard as a result. This led to numerous COFF extensions. IBM used the XCOFF format in AIX; DEC, SGI and others used ECOFF; and numerous SysV ports and tool chains targeting embedded development each created their own, incompatible, variations. With the release of SVR4, AT&T replaced COFF with ELF. While extended versions of COFF continue to be used for some Unix and Unix like platforms, primarily in embedded systems, perhaps the most widespread use of the COFF format today is in Microsoft's Portable Executable (PE) format. Developed for Windows NT, the PE format (sometimes written as PE/COFF) uses a COFF header for object files, and as a component of the PE header for executable files.
Особенности
Основным улучшением COFF по сравнению с a.out стало введение нескольких именованных секций в объектном файле. Разные объектные файлы могли содержать разное количество и типы секций.
COFF's main improvement over a. out was the introduction of multiple named sections in the object file. Different object files could have different numbers and types of sections.
Символическая информация для отладки
Символическая информация для отладки COFF состоит из символических (строковых) имен для программных функций и переменных, а также информации о номерах строк, используемой для установки точек останова и трассировки выполнения. Символические имена хранятся в таблице символов COFF. Каждая запись в таблице символов включает имя, класс хранения, тип, значение и номер секции. Короткие имена (8 символов или меньше) хранятся непосредственно в таблице символов, более длинные имена – как смещение в таблице строк, расположенной в конце COFF-объекта. Классы хранения описывают тип сущности, которую представляет символ, и могут включать внешние переменные (C EXT), автоматические (стековые) переменные (C AUTO), регистровые переменные (C REG), функции (C FCN) и многие другие. Тип символа описывает интерпретацию значения сущности символа и включает значения для всех типов данных C. При компиляции с соответствующими опциями COFF-объектный файл содержит информацию о номерах строк для каждой возможной точки останова в текстовом разделе объектного файла. Информация о номерах строк представлена в двух формах: в первой, для каждой возможной точки останова в коде, запись в таблице номеров строк содержит адрес и соответствующий номер строки. Во второй форме запись указывает на запись в таблице символов, представляющую начало функции, что позволяет установить точку останова по имени функции. Важно отметить, что COFF не поддерживал представление номеров строк или отладочных символов для подключаемых исходных файлов, таких как файлы заголовков, что делало информацию об отладке COFF практически бесполезной без несовместимых расширений.
The COFF symbolic debugging information consists of symbolic (string) names for program functions and variables, and line number information, used for setting breakpoints and tracing execution. Symbolic names are stored in the COFF symbol table. Each symbol table entry includes a name, storage class, type, value and section number. Short names (8 characters or fewer) are stored directly in the symbol table; longer names are stored as an offset into the string table at the end of the COFF object. Storage classes describe the type entity the symbol represents, and may include external variables (C EXT), automatic (stack) variables (C AUTO), register variables (C REG), functions (C FCN), and many others. The symbol type describes the interpretation of the symbol entity's value and includes values for all the C data types. When compiled with appropriate options, a COFF object file will contain line number information for each possible break point in the text section of the object file. Line number information takes two forms: in the first, for each possible break point in the code, the line number table entry records the address and its matching line number. In the second form, the entry identifies a symbol table entry representing the start of a function, enabling a breakpoint to be set using the function's name. Note that COFF was not capable of representing line numbers or debugging symbols for included source as with header files rendering the COFF debugging information virtually useless without incompatible extensions.
Относительный виртуальный адрес
Когда генерируется COFF-файл, обычно неизвестно, по какому адресу в памяти он будет загружен. Виртуальный адрес, по которому будет загружен первый байт файла, называется базовым адресом образа. Остальная часть файла не обязательно загружается в непрерывный блок, а в различные секции. Относительные виртуальные адреса (RVA) не следует путать со стандартными виртуальными адресами. Относительный виртуальный адрес – это виртуальный адрес объекта из файла после его загрузки в память, уменьшенный на базовый адрес образа файла. Если бы файл отображался в память непосредственно с диска, RVA совпадал бы со смещением в файле, но такое происходит довольно редко. Следует отметить, что термин RVA используется только для объектов внутри файла образа. После загрузки в память к базовому адресу образа прибавляется значение, и используются обычные виртуальные адреса.
When a COFF file is generated, it is not usually known where in memory it will be loaded. The virtual address where the first byte of the file will be loaded is called image base address. The rest of the file is not necessarily loaded in a contiguous block, but in different sections. Relative virtual addresses (RVAs) are not to be confused with standard virtual addresses. A relative virtual address is the virtual address of an object from the file once it is loaded into memory, minus the base address of the file image. If the file were to be mapped literally from disk to memory, the RVA would be the same as that of the offset into the file, but this is actually quite unusual. Note that the RVA term is only used with objects in the image file. Once loaded into memory, the image base address is added, and ordinary VAs are used.
Проблемы
Заголовок файла COFF хранит дату и время создания объектного файла в виде 32-битного двоичного целого числа, представляющего собой количество секунд, прошедших с начала эпохи Unix – 1 января 1970 года 00:00:00 UTC. Даты, наступающие после 19 января 2038 года, не могут быть сохранены в этом формате, что является проявлением проблемы 2038 года.
The COFF file header stores the date and time that the object file was created as a 32 bit binary integer, representing the number of seconds since the Unix epoch, 1 January 1970 00:00:00 UTC. Dates occurring after 19 January 2038 cannot be stored in this format, resulting in an instance of the year 2038 problem.