Атқарылатын файл форматтары: COFF және оның вариациялары
COFF
COFF форматы – Unix жүйелеріндегі орындалатын файлдар форматы. ELF-ке дейін кең қолданылды, қазір де Windows, UEFI жүйелерінде қолданылады. Бағдарлама жасауда маңызды!
Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Орындалатын файл пішімі
Executable file format
Common Object File Format (COFF) – Unix жүйелерінде қолданылатын орындалатын файлдар, объектілік код және ортақ кітапхана компьютерлік файлдарының форматы. Ол Unix System V жүйесінде енгізілді, бұрын қолданылған a.out форматын ығыстырды және SVR4-пен ұсынылған ELF форматымен кеңінен алмастырылмас бұрын XCOFF және ECOFF сияқты кеңейтілген спецификациялардың негізін қалады. 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 жылы AT&T-тің UNIX System V жүйесінде VAX емес, 32 биттік платформалар үшін, мысалы 3B20 үшін енгізілді. Ағымдағы AT&T a.out форматынан жақсартылған өзгерістерге кездейсоқ бөлімдер, нақты процессор жарияланымдары және нақты мекенжай байланысы кірді. Дегенмен, COFF дизайны тым шектеулі және толық емес болды: бөлімдердің максималды санына, бөлім атауларының ұзындығына және бастапқы файлдарға шектеулер қойылды, ал символдық қате туралы ақпарат C сияқты нақты тілдерді, тіпті C++ сияқты жаңа тілдерді немесе жаңа процессорларды қолдауға қабілетсіз болды. Осының салдарынан COFF-тың нақты іске асырылуы міндетті түрде стандартты бұзды. Бұл көптеген COFF кеңейтімдеріне әкелді. IBM AIX-те XCOFF форматын пайдаланды; DEC, SGI және басқалары ECOFF-ты пайдаланды; ал көптеген SysV порттары мен құралдар тізбегі кіріктірілген әзірлемеге бағытталған әрқайсысы өздерінің үйлесімсіз нұсқаларын жасады. SVR4 нұсқасымен AT&T COFF-ты ELF-ке алмастырды. COFF-тың кеңейтілген нұсқалары әлі де кейбір Unix және Unix-қа ұқсас платформаларда, әсіресе кіріктірілген жүйелерде қолданылып келеді, бірақ бүгінде COFF форматының ең кең таралған түрі Microsoft-тың Portable Executable (PE) форматы болып табылады. 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 биттік бинарлық бүтін сан түрінде сақтайды, бұл 1970 жылдың 1 қаңтары, 00:00:00 UTC Unix дәуірінен бергі секундтар санын көрсетеді. 2038 жылдың 19 қаңтарынан кейінгі күндерді осы форматта сақтау мүмкін емес, соның салдарынан 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.